Compatibility improvement to reparse point handling.

[Joe Lowe]

On 2017-04-28 03:21, Corinna Vinschen wrote:
> 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.

OK. Got it.

> 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.

Agreed, "directory junction" as created with the "cmd /c mklink /j ..." 
. This ends up on disk as a reparse point with tag 
IO_REPARSE_TAG_MOUNT_POINT, same tag as a volume 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.

I have no problem with any such changes. Feel free to modify the patch 
as desired, or I can make changes. I avoided string compares mainly 
because of the style of the logic in posixify(), and uncertainty about 
performance concerns. The drive letter prefix check will still take more 
that just a string compare.

Reparse point targets can point anywhere in the native NT object 
namespace, so there is an unbounded set of potential target prefixes 
that will not convert to posix symlinks. If the logic is changed to use 
string constants, it still needs to compare against a complete list of 
known convertible prefixes (currently two), as opposed to an unavoidably 
incomplete list of known non-convertible prefixes.

> - 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.

IMO: I think the current Cygwin logic is good in this regard. Any 
symlink created by a user with Cygwin tools or with native "cmd /c 
mklink" works today as a posix symlink to Cygwin applications.

The ability for a technical user or 3rd party developer to create a 
reparse point that does not get treated as a posix symlink in Cygwin 
applications, is a useful feature. This would be equivalent to a linux 
user choosing to use a "bind" mount point instead of a symlink.

> - 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.

Timing is not an issue. Please ping me when you are back if you want me 
to modify the patch. Enjoy your time away.


> Thanks,
> Corinna
>