Re: Compatibility improvement to reparse point handling.

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Joe,


firt thanks for the patch.  In theory patches should go to the
cygwin-patches mailing list but cygwin-developers is ok for now.

On Apr 27 13:39, Joe Lowe wrote:
> Example of current Cygwin behavior:
> 
> A junction with this SubstituteName value
> "\Device\HarddiskVolume4\Users\joe\Documents" works in windows applications
> to open my documents folder, but in Cygwin applications it does not work.
> Cygwin treats the junction as a posix symlink with a target of
> "/cygdrive/c/Device/HarddiskVolume4/Users/joe/Documents", which does not
> exist.

A "junction"?  I'd just like to make sure that we're talking about the
same reparse point type.  A junction is handled by an
IO_REPARSE_TAG_MOUNT_POINT.

> 1) The UNC prefix causes the reparse target to go through the MUP
> (Multi-UNC-Provider) arbitration process. This process involves network IO
> and timeouts that for 3rd party file systems are likely unnecessary. This
> negatively effects user experience and it leaks local system activity onto
> the network. Also, the UNC prefix is not appropriate for local volumes.
> 
> 2) Drive letters are limited. Junctions and symlinks to volumes without
> drive letters cannot have the drive letter prefix.
> 
> 3) The volume GUID prefix implies a mount point for a local volume managed
> by the windows plug-and-play system and volume manager. Some applications
> will interpret volumes with mount points in this format as having certain
> attributes or features. At a minimum, the volume GUID prefix is not
> appropriate for reparse points targeting network volumes, and is not handled
> by Cygwin for symbolic link type reparse points.

As far as IO_REPARSE_TAG_MOUNT_POINT types are concerned the volume GUID
prefix is already handled, line 2321 in git HEAD.

> License:
> 
> The patch is entirely my own work. I do not consider the patch substantial
> enough for copyright to apply, but if licensing is considered necessary then
> the patch is licensed as follows.
> 
> 2-clause BSD:

Thank you.  Your patch is substantial and requires the 2-clause BSD waiver
per https://cygwin.com/contrib.html.  See also
https://cygwin.com/git/?p=newlib-cygwin.git;f=winsup/CONTRIBUTORS;hb=HEAD

> Feedback appreciated.

Your patch is basically ok, I have three points, though:

- The is_absolute_reparse_target_posix_symlink_compatible function
  doesn't only have a somewhat too long name, it's also too complicated
  for my taste.  We already handle path prefix in the code and so far
  they are handled differently most of the time.  For instance, see
  the aforementioned line 2321 in git:
  https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;h=7d1d23d72cf1d9833683e139c06e4c282363dc1c;hb=HEAD#l2321

  We also have matching constants wchar_t strings for other comparison
  operations, which I'd prefer to use in this code:
  https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/globals.cc;h=5c5d64ee44b762e6655153b7d4b651591b65c1ba;hb=HEAD#l119

  The "UNC" string is always upper case.

- As far as \Device\HarddiskVolumeX paths are concerned, we might want
  to handle them actually as valid symlinks.  We could most easily
  accomplish that by prepending "/proc/sys/" to the string when
  converting them to POSIX paths.

  That's not quite as easy for IO_REPARSE_TAG_MOUNT_POINT paths starting
  with the GUID volume given the way the NT namespace is mapped into
  /proc/sys.  It depends on the fact whether the volume has been mounted
  globally or if it's a user mount point.  For a start it would actually
  be easier to handle them just as files or dirs, but I'd appreciate
  ideas as to how we could handling them as symlinks.

- Last but not least, your timing is a bit bad.  I'll be offline for all
  of May, starting tomorrow.  We can discuss this further in June.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature