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