X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=nfpEBG8lJ8DTZO4S+68KBXGyMC+GKmhZdMwnrK5e/YceKZy5gvfNj
	Kv6M2blsaF0k1U8k7MtnUwFYSHS0lAMcCl500KcUognxtVm9p63zw8fbxus22Qux
	Gq2LMwQNRGuYFZj3WR4w93OtLL7jbujGWsIhWU0mEYOkmTB6tXpQTg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=mXbAaGBLIEmDOMVRspCg9cVSWWc=; b=kvvmFjBFXLXX84yN/j+LSvZiaLvi
	GC21ACOroExRw29YUXleE+gohEDnIZx7FV7GanWf5sDGhSd9NyJrh2TSk6ToSL+N
	3f0wg9Zg1JG3SB7AdXPaOlEYsF77PlAyjNW4Er4z7IjFRdBLcPHOtXWULa3w0MXI
	/qtFSMet8Z7JmbE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-101.5 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=utilizes, cch, vista, Regarding
X-HELO:	drew.franken.de
Date:	Thu, 25 Aug 2016 14:45:12 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: FUSE, symbolic links and special files
Message-ID:	<20160825124512.GE9783@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<D3E490C7.AEB9%billziss AT navimatics DOT com>
MIME-Version:	1.0
In-Reply-To:	<D3E490C7.AEB9%billziss@navimatics.com>
User-Agent:	Mutt/1.6.2 (2016-07-01)

--Ns7jmDPpOpCD+GE/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 25 11:46, Bill Zissimopoulos wrote:
> Turns out that Microsoft already has a solution for special files on NFS:
>=20
> https://msdn.microsoft.com/en-us/library/dn617178.aspx
>=20
> I see no reason that the same solution cannot be used for FUSE for Cygwin
> as well.

On NFS Cygwin utilizes the information available via extended attributes
so far.  There's an extended attribute you can give to NtCreateFile
to indicate that you want to act on the link, not on the file the link
points to.  The EA method is used for stata() as well to fetch the NFS
FATTR3 structure.  See winsup/cygwin/nfs.{cc,h} for details.

What bugs me is that I wasn't aware that there's also a reparse point
implementation for NFS.  When I wrote the original code accessing
NFS, the MSFT guys working on NFS gave me a hint or two how to access
this information, but there was no talk about reparse points at all :(

Since when is this RP method available?  Unfortunately the above MSDN
page doesn't tell...  Was it already available with Vista?  Does anybody
know?

Hmm.

This might allow to speed up symlink_info::check since the entire
code to read the EA could go away and the functionality of check_nfs_symlink
could be folded into check_reparse_point.  But...

In the following OP is the originating process, CW is the Cygwin
> layer, WL is the WinFsp layer and FL is the FUSE layer.
>=20
> OP: mkfifo("myfifo")
> CW: NtCreateFile, NtDeviceIoControlFile(FSCTL_SET_REPARSE_POINT)
> [NFS_SPECFILE_FIFO]
> WL: IRP_MJ_FILE_SYSTEM_CONTROL/FSCTL_SET_REPARSE_POINT [NFS_SPECFILE_FIFO]
> FL: fuse_operations::mknod("myfifo", S_IFIFO)
>=20
> Regarding symbolic link support specifically I am still undecided on
> whether the right thing to do is to use NTFS symbolic links
> (IO_REPARSE_TAG_SYMLINK) or use NFS_SPECFILE_LNK for the FUSE layer. My
> inclination is to support both and let the FUSE file system developer
> decide on their preference.
>=20
> Any comments welcome.

...it needs thorough testing(*).  There's a good chance that the NFS RP
buffer is not exposed to user space, but instead only handled by the NFS
driver.  *If* the RP method works fine in user space, I'm inclined to do
as outlined above and get rid of the EA stuff in symlink_info::check
since it could be transparently shared between NFS and WinFSP.


Corinna

(*) https://cygwin.com/acronyms/#SHTDI

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--Ns7jmDPpOpCD+GE/
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXvuhYAAoJEPU2Bp2uRE+g0PsP/0Sj8X3Gn9sTPwB/ZfK3fxfw
ccY7j2BhV1UW0890J9f8e8kCqnFFZrytWqEYXVk7LyPPYFQitf8W5gbcuZ7lySsC
nGvao9rsX7uAxoFzriNgbL91CIZtRRGBrplsXObm6U6GQy/tjPw6/0ajIQKtoLb9
1//HAc+4+ci5JH6zYO9O0qXYxHBRitNmFJBuSHkFeuGNAVG00xGGWETqac4oDzFY
nTHt6X+v29C+BfUIANmvXNc0uSbiv0/n4a5lHYsKDaDC+7Ld4aNPsGtdoe1cWkJ1
OdnCZWjm8ChHOT619F9J6PhDT8QdBBBoC9Cs75PDt5YSsoKzDCa4VfhFJkwdP/O3
8rnC5fySZ9atDqgxvNvg9epTUA/wBg1cHL2dQXBVsB8uX3jmW2gZ6qiQDimdF8Tr
BEiBJ+6Q5pLoEyzqGdEe3zBg2M549GC/uWzrkSvJDmKjPiuZ7QmpC9k+skgXh+dH
pb87zUQyaOqwcmiimgHkydezXHqU+cjIE/9d17sl0kzI3+kU8fWeV3iE5NxEnxuL
jScvC2tvyIHvIK9+Sh1gF0Ce6tInK8pNsDTMeS12YGzJNVEfJxLqBy60DTeVv5kS
ynZx0ehSLN45haQLpVdZjPE3wmeti9TVh58jbZs+sHhUaeprv1dSYQRFfmZwGKQs
h/GixDaPm7yxWvaAJBdQ
=+Xr1
-----END PGP SIGNATURE-----

--Ns7jmDPpOpCD+GE/--

- Raw text -