FUSE, symbolic links and special files
Corinna Vinschen
corinna-cygwin@cygwin.com
Fri Aug 26 10:25:00 GMT 2016
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.
>
> I agree. FYI I have not tested the use of NFS reparse points yet, although
> I intend to.
>
> 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.
>
> Let us consider the expected behavior of an NFS_SPECFILE_LNK reparse point
> (this is speculation) during NtCreateFile:
>
> - On NTFS prior to Win8:
> - STATUS_IO_REPARSE_TAG_NOT_HANDLED
...so this shouldn't happen to us, right?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20160826/7166f003/attachment.sig>
More information about the Cygwin
mailing list