DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5169oZP92267965
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D46D43858CD1
Date: Thu, 6 Feb 2025 12:47:24 +0300
Message-ID: <1084215042.20250206124724@yandex.ru>
To: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
Subject: Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote
 filesystems in Cygwin ?
In-Reply-To: <Z6OKLXP-wTlVzYAb@calimero.vinschen.de>
References: <CAKAoaQ=c44QKPSN0=pweE+H=n2opxPnRjqVwcorow=y=_7TCHw AT mail DOT gmail DOT com> 
 <35e9e310-91d7-41e5-7e98-c1658030e912 AT jdrake DOT com>
 <Z6OKLXP-wTlVzYAb AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Precedence: list
From: Andrey Repin via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Andrey Repin <anrdaemon AT yandex DOT ru>
Content-Type: text/plain; charset="cp1250"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

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.


-- 
With best regards,
Andrey Repin
Thursday, February 6, 2025 12:44:40

Sorry for my terrible english...

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