On Feb 6 12:47, Andrey Repin via Cygwin wrote:
> Greetings, Corinna Vinschen via Cygwin!
>
> > On Feb 4 14:47, Jeremy Drake via Cygwin wrote:
> >> On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> >>
> >> > it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> >> > "remote" filesystems:
> >> > ---- snip ----
> >> > 2582 /* Don't handle junctions on remote filesystems as
> >> > symlinks. This type
> >> > 2583 of reparse point is handled transparently by the OS so
> >> > that the
> >> > 2584 target of the junction is the remote directory it is
> >> > supposed to
> >> > 2585 point to. If we handle it as symlink, it will be
> >> > mistreated as
> >> > 2586 pointing to a dir on the local system. */
> >> >
> >> > The matching code in our filesystems seems to work in PowerShell and
> >> > cmd.exe - so what context am I missing ?
> >>
> >> The comment seemed to explain it pretty well. Junctions are always
> >> absolute. If it is absolute to a local path, that path is local to the
> >> server, not the client. If Cygwin treated it as a symlink, it would see
> >> the target as /cygdrive/c/whatever and would try to follow that to the
> >> client-local directory. By *not* treating those as symlinks, it will
> >> instead treat them as ordinary directories to be traversed, which will
> >> allow the OS to handle them as normal.
>
> > Well explained.
>
> >> Perhaps it could be relaxed to allow remote junctions to be treated as
> >> symlinks if their targets are UNC rather than local? Is that the case
> >> your filesystems are exposing?
>
> > Just to be clear, there are two types.
>
> > The official volume mount points using the GUID-style volume names as
> > introduced with the Vista volume manager shouldn't be touched at all for
> > the reason stated above.
>
> > The junctions points are usually pointing to some local directory
> > in the form \??\X:\... We can't use them for the same reason.
>
> > But if your NFS client would be so kind to convert them to the UNC
> > type of path, i. e., \??\UNC\server\path, then we could test it in
> > Cygwin and actually expose them as symlinks.
>
> > However, is it really worth the effort?
>
> > Right now, those remote reparse points of type
> > IO_REPARSE_TAG_MOUNT_POINT are transparently handled by the OS, that's
> > why there's no problem using them in PS or cmd. They are just passed
> > through.
>
> > In Cygwin, symlinks of any type are handled as symlinks. That means,
> > evaluating a path with a symlink requires to open the symlink and read
> > the target path from it, then replace parts or all of the current path
> > with the symlink content, to create a final POSIX/Win32 path pair from
> > it.
>
> > So you have a (small) performance hit, for the not so obvious gain to
> > see a remote junction as symlink in Cygwin.
>
> > I'm not judging here, I'm really asking for your opinion.
>
> To add another stone to the pile,
>
> $ fsutil behavior set symlinkEvaluation
>
> …
> symlinkEvaluation {L2L|L2R|R2R|R2L}:{0|1} [...]
> …
>
> Sample SymlinkEvaluation command:
> "fsutil behavior set symlinkEvaluation L2L:1 L2R:0"
> - Will enable local to local symbolic links and disable local to
> remote symbolic links. It will not change the state of remote to
> remote links or remote to local links.
> - This operation takes effect immediately (no reboot required)
>
> The platform behavior could be different from user's expectations. And it is
> not library's job to second-guess the OS behavior.
Good point, but I don't think this affects IO_REPARSE_TAG_MOUNT_POINT
reparse points. This should (afaik, grain of salt and all that) only
affect reparse points of type IO_REPARSE_TAG_SYMLINK.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
