Re: FUSE, symbolic links and special files

[Bill Zissimopoulos <billziss@navimatics.com>]

On 8/26/16, 4:59 PM, cygwin-owner@cygwin.com Bill Zissimopoulos wrote:


>On 8/26/16, 11:05 AM, Corinna Vinschen wrote:
>
>>On Aug 25 19:04, Bill Zissimopoulos wrote:
>>>- 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?
>
>I think so.
>
>I will continue with the implementation/testing of reparse points and
>report back when I have more.

I have finally completed the implementation of reparse points for WinFsp.
I have also implemented NFS reparse point support for WinFsp-FUSE.

I tested this implementation with Cygwin although my testing was general
command line use and not rigorous. For this purpose I cobbled together a
patch for Cygwin; the patch is low quality and I hesitate to post it here,
but I can if so desired. Effectively I changed the implementation of
Cygwin’s mknod_worker, symlink_info::check_reparse_point and
readdir_check_reparse_point to understand and use NFS reparse points.

I am unclear on how to proceed from here. Although I do not understand the
Cygwin internals well enough and have rather limited time at the moment I
could try cleaning up the patch and officially submitting.

I am also thinking that using reparse points for POSIX special files on
other file systems that support it (i.e. NTFS) may be something that the
list should consider.

Bill