FUSE, symbolic links and special files

[Bill Zissimopoulos <billziss@navimatics.com>]

While on vacation I have been (slowly) working to add reparse point and
symbolic link support for WinFsp and FUSE for Cygwin. This work is mostly
complete and is currently being tested.

I am writing to the Cygwin list because I want to resolve a problem that
Herbert Stocker originally brought up:

>F) Pipes:
>> [Quick experiment:
>>
>> $ mkfifo foo; cmd /c dir 'foo*' | grep foo; rm foo
>> 06/16/2016  11:02 PM               130 foo.lnk
>> ]
>>
>> Ok, so they are shortcuts. Naturally they are supported.
>
>    I think they are not.
>    The mkfifo system call will have Cygwin create a .lnk file and
>    WinFsp will forward it as such to the file system process. The
>    sytem calls readdir or open will then have the file system
>    process tell WinFsp that there is a .lnk file and Cygwin will
>    translate this back to a fifo, so in this sense it does work.
>
>    But the file system will see a file (with name *.lnk) where it
>    should see a pipe (mknod call with 'mode' set to S_IFIFO).
>    IMHO one could say this is a break of the FUSE API.
>
>    Practically it will break:
>     - file systems that special-treat pipe files (or .lnk files).
>
>     - If one uses sshfs to connect to a Linux based server and
>       issues the command mkfifo foo from Cygwin, the server will
>       end up with a .lnk file instead of a pipe special file.
>
>     - Imagine something like mysqlfs, which stores the stuff in a
>       database. When you run SQL statements to analyze the data
>       in the file system, you won't see the pipes as such. Or if
>       you open the file system from Linux you'll see the .lnk
>       files.

Herbert is of course right. A .lnk file is not a FIFO to any system other
than Cygwin. I have been thinking about how to solve this problem and I
believe I have an answer in the form of reparse points.

Reparse points can be viewed as a form of special metadata that can be
attached to a file or directory. The interesting thing about reparse
points is that they can have special meaning to a file system driver
(NTFS/WinFsp), a filter driver (e.g. a hierarchical storage system) or
even an application (Cygwin).

NTFS uses reparse points to implement symbolic links and places severe
limitations on them. For one, it differentiates between file and directory
symlinks. It also requires the SE_CREATE_SYMBOLIC_LINK_PRIVILEGE privilege
to be held to create a symbolic link account.

Interestingly it does not perform any extraneous access checks on other
reparse points. IMO this makes reparse points very interesting because it
offers a path for WinFsp and FUSE for Cygwin to provide special file
support.

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

Bill