This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Compatibility improvement to reparse point handling.
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