Re: FUSE, symbolic links and special files

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

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

On Aug 25 11:46, Bill Zissimopoulos wrote:
> Turns out that Microsoft already has a solution for special files on NFS:
> 
> https://msdn.microsoft.com/en-us/library/dn617178.aspx
> 
> 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.
> 
> 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)
> 
> 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.
> 
> 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

-- 
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 --]