public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: cygwin@cygwin.com
Subject: Re: FUSE, symbolic links and special files
Date: Thu, 25 Aug 2016 19:04:00 -0000	[thread overview]
Message-ID: <223d291e-689f-15f8-cca2-efbe972e123c@secure-endpoints.com> (raw)
In-Reply-To: <20160825152127.GL9783@calimero.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]

  reply	other threads:[~2016-08-25 16:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25 12:49 Bill Zissimopoulos
2016-08-25 13:04 ` Corinna Vinschen
2016-08-25 13:38   ` Jeffrey Altman
2016-08-25 13:54     ` Corinna Vinschen
2016-08-25 14:52       ` Jeffrey Altman
2016-08-25 15:59         ` Corinna Vinschen
2016-08-25 19:04           ` Jeffrey Altman [this message]
2016-08-25 19:41             ` Bill Zissimopoulos
2016-08-25 21:15         ` Bill Zissimopoulos
2016-08-25 19:15   ` Bill Zissimopoulos
2016-08-26 10:25     ` Corinna Vinschen
2016-08-26 14:35       ` Bill Zissimopoulos
2016-09-20 22:02         ` Bill Zissimopoulos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=223d291e-689f-15f8-cca2-efbe972e123c@secure-endpoints.com \
    --to=jaltman@secure-endpoints.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).