FUSE, symbolic links and special files

Bill Zissimopoulos billziss@navimatics.com
Tue Sep 20 22:02:00 GMT 2016


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



More information about the Cygwin mailing list