Re: FUSE, symbolic links and special files

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]