Re: FUSE, symbolic links and special files

[Bill Zissimopoulos <billziss at navimatics dot com>]

On 8/25/16, 3:45 PM, Corinna Vinschen wrote:

>On Aug 25 11:46, Bill Zissimopoulos wrote:
>>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.

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:

- The first case is during the processing of NtCreateFile (without the
FILE_OPEN_REPARSE_POINT flag set). In this case the file system driver
will return STATUS_REPARSE and either:
	- Return a path that NTOS will resend to the file system driver for
further processing (useful for symlink-style processing), or...
	- Return a reparse data buffer that some higher-level component (e.g. a
filter driver) may interpret specially. For example, a hierarchical
storage management system may download a file pointed to by a reparse
point locally. If there is no higher-level component that knows about the
reparse point, I believe the NTOS IO manager will return
STATUS_IO_REPARSE_TAG_NOT_HANDLED.

- 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

- On NFS prior to Win8:
	- STATUS_IO_REPARSE_TAG_NOT_HANDLED

- On FUSE for Cygwin prior to Win8:
	- STATUS_SUCCESS with file pointed by symlink opened (because the WinFsp
FSD would know how to handle NFS reparse points).

- On NTFS after Win8:
	- Likely STATUS_IO_REPARSE_TAG_NOT_HANDLED, although there is a
possibility that Microsoft has built knowledge of the NFS_SPECFILE_LNK
reparse point into the NTFS FSD or another filter driver, in which case
the file would be opened and the return would be STATUS_SUCCESS.

- On NFS after Win8:
	- STATUS_SUCCESS with file pointed by symlink opened.

- On FUSE for Cygwin prior to Win8:
	- STATUS_SUCCESS with file pointed by symlink opened.


This is not ideal, because sometimes an NtCreateFile of an
NFS_SPECFILE_LNK reparse point will result in STATUS_SUCCESS and sometimes
it will result in STATUS_IO_REPARSE_TAG_NOT_HANDLED. I can imagine of
course that the NtCreateFile call could be retried with
FILE_OPEN_REPARSE_POINT followed by FSCTL_GET_REPARSE_POINT and symlink
resolution could happen in user mode.

Bill