This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FUSE, symbolic links and special files


On 8/25/2016 11:21 AM, Corinna Vinschen wrote:
> On Aug 25 10:46, Jeffrey Altman wrote:
>> On 8/25/2016 9:16 AM, Corinna Vinschen wrote:
>>> On Aug 25 09:04, Jeffrey Altman wrote:
>>>> On 8/25/2016 8:45 AM, Corinna Vinschen wrote:
>>>>> Since when is this RP method available?  Unfortunately the above MSDN
>>>>> page doesn't tell...  Was it already available with Vista?  Does anybody
>>>>> know?
>>>>
>>>> #define IO_REPARSE_TAG_NFS
>>>>
>>>> was added in the Windows 8.0 DDK.
>>>
>>> Thank you.  Too bad, so we have to stick to the EA method to accommodate
>>> Vista and W7.
>>
>> I don't believe there is any restriction from using this tag on Vista or
>> Win7.  It will be stored on NTFS just as any other Reparse Tag would be.
>>  NTFS and ReFS will ignore it just as they would on Win8 or Win10.
> 
> Sorry, but I don't grok that.  Why would I create a reparse point on
> NTFS with this value?  This RP type would only be interesting if I can
> access the information for files on a non-Windows remote filesystem to
> indicate special file types.

If you want the underlying remote file system to parse the value then
you can't set it anywhere except on the file system that returns
protocol type

  WNNC_NET_MS_NFS  0x00420000

because that is the only file system for which it is known supports the
Microsoft reparse tag

  IO_REPARSE_TAG_NFS                      (0x80000014L)

Since it is a Microsoft TAG it means that it can be interpreted by any
file system.  For example, I could add support for it to OpenAFS as an
alternative method of creating and reporting symlinks instead of

  IO_REPARSE_TAG_SYMLINK                  (0xA000000CL)

or

  IO_REPARSE_TAG_OPENAFS_DFS              (0x00000037L)

Only one of the reparse tag types can be reported at a time so the
choice of which reparse tag to use could be left up to configuration or
be set via an FSCTL on a per process basis.

Ideally Cygwin would obtain its own IO_REPARSE_TAG_xxxx value to use and
then any file system that wants to support Cygwin can simply add support
for it.  Whether that be FUSE or OpenAFS or an NFS implementation, etc.

FUSE should also be sure to obtain its own WNNC_NET_xxxx value to use.

> Granted, it *could* be used by Cygwin on NTFS to indicate Cygwin's own
> implementations of AF_LOCAL sockets or fifos.  Or even for symlinks.
> But that would only introduce YA symlink type which would be unusable
> from non-Cygwin applications.

Correct.

With its own reparse tag Cygwin could store exactly the same metadata it
stores today in the data stream of the .lnk file as reparse tag data.
The benefit of applying a reparse tag is that the .lnk will no longer be
confused for a regular file.   On file systems that do not support
reparse points it can continue to store the data in the data stream.

> Or am I missing something?

I doubt it.

> 
> Thanks,
> Corinna

Anytime.

Jeffrey Altman


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]