|IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote filesystems in Cygwin ?

Thu Feb 6 08:42:21 GMT 2025

On Wed, 5 Feb 2025 at 16:56, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>> 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?

Another issue: Any new feature in ms-nfs41-client must be
backwards-compatible to Cygwin 3.3 32bit, to support Windows 10/32bit,
unless someone ports Cygwin 3.6 to 32bit.
Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur