DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 516CP3RV2316691
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 516CP3RV2316691
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=cxXjw/tW
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5513A385841F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1738844701;
	bh=l/CjdVGGh0DzJ4RZ4cMXhEjYFdczUTpcAViqi1rtcEc=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=cxXjw/tWGBy7hW5L4RA+c0fxBx2VqHJtdlKMkT4W+sQzHCG9nTwrUOEWVyxmxQePA
	 DD1t71ujDMQrmzwfsl7zSi3nBKaykBMFlc/dD4oy80KgBj/w5eLEPK4IzM9tWQMbMb
	 Kpbc8NPlZn5DK+XreSRhZP/ZevLa6tEFjyDtzQ/Y=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B925E3858CD1
Date: Thu, 6 Feb 2025 13:24:37 +0100
To: cygwin AT cygwin DOT com
Subject: Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote
 filesystems in Cygwin ?
Message-ID: <Z6SqBU84BGW7jOKe@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
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>
 <1084215042 DOT 20250206124724 AT yandex DOT ru>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1084215042.20250206124724@yandex.ru>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="utf-8"
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
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 516CP3RV2316691

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