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=Cjs5qa+SGKw30D85QA2Nnhp4O7KKdTgjb1GVQn9dMf8Ulu6+P56Z1
	GxfrhAlCpgWT6REgauETQDcwYNEcOE7P2gXfu4T7PcUpf52zhfKWKfwHEnXsZXW8
	N+khl495J+ZoJaZwA9uDgbIiGDOWFkmd+5eJRVw6QdeRkjhqSVaXeI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 26 Aug 2016 10:05:51 +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: <20160826080551.GA23935@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> <20160825124512 DOT GE9783 AT calimero DOT vinschen DOT de> <D3E512D6.AF5F%billziss AT navimatics DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j"
Content-Disposition: inline
In-Reply-To: <D3E512D6.AF5F%billziss@navimatics.com>
User-Agent: Mutt/1.6.2 (2016-07-01)

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

On Aug 25 19:04, Bill Zissimopoulos wrote:
> On 8/25/16, 3:45 PM, Corinna Vinschen wrote:
> >...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.
>=20
> I agree. FYI I have not tested the use of NFS reparse points yet, although
> I intend to.
>=20
> My expectation is that there should not be any issue accessing such
> reparse points from user mode. My understanding of the reparse point
> mechanism is that it comes into play in a couple of cases:

No, me neither, but the MSDN documentation is, shall we say, limited...

> - The first case is during the processing of NtCreateFile (without the
> FILE_OPEN_REPARSE_POINT flag set).

This case doesn't matter to us.  Cygwin always opens the file with
FILE_OPEN_REPARSE_POINT set...

> - The second case is through direct manipulation of the reparse point
> using FSCTL_GET_REPARSE_POINT, FSCTL_SET_REPARSE_POINT and
> FSCTL_DELETE_REPARSE_POINT.
>=20
> Let us consider the expected behavior of an NFS_SPECFILE_LNK reparse point
> (this is speculation) during NtCreateFile:
>=20
> - On NTFS prior to Win8:
> 	- STATUS_IO_REPARSE_TAG_NOT_HANDLED

...so this shouldn't happen to us, right?


Corinna

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

--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJXv/heAAoJEPU2Bp2uRE+g12kP/0xtG+Urmm8EGJg2uC6XTUFc
8ezJt+l3YC7zrxMOFYeJG0+Cd0mbdRaNuBQfvfqM4UrSluABHCFNQ3e0lvfKF8FR
21/xYNBsD9oVArSviZO/EVG8cydhkzNPicH0+gCRBnfr8WMxaCUxYIYMm5WZBDut
bqLI+J7T0/gzP3VYVpOfuuI7Z53jR9tIDVXBIv5egkcxWcRkJFei94TlD8HKyyxT
NeePPDeZiKeZEEfI80I/UEBf+ePMstKB49StRKhmOUd4UNbrJPsWQwcHuCs8ddU+
RqXo5GGPMetzbYD+/WCvRWNrqCfkGSu/uUpOUVU4sJfNWaoQeZQLzalT3xrtAT33
agVPDZYY1UjJtJzQbHxScgljULoOSyYzv6OHEqF6AYlviUWwvkbVEKExrhnAC6vt
Ao2CFIvXr/VfuqDqz/TSa77ZwFU4qdtaX+8UZQF11qMnflfgsOaw9aTpznZFoM/W
bsCa/jPpdbiUK68MrmxF85yQ8tjBuMrCydsDXt/F74THga8yzun5o+3Xc6xpp18i
WFGJLhM0RRilN9Iw3WJ/nh3rsWjd5kEHsQj3c4XoPhotXG/3oEQtoLyP/5beJUDc
chfuToUDo0Lg6GTsceyJ+Vsz5lz4z296TM0/TA7QNNWeJ7Kfq9SKOCrHzRX70enu
RMqPSJQC8YuENrOEj0TY
=xVXb
-----END PGP SIGNATURE-----

--nFreZHaLTZJo0R7j--