DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 515FvZ5o1930230
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 515FvZ5o1930230
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=SjXfXd4x
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 833EC3858420
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1738771051;
	bh=2eC8JWAkfgDFLv/ZKU+WclQtpXlbcUkOjgoMw25IPEU=;
	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=SjXfXd4x3X6fd1a0bswUsn668gLDH5jzFLw9oy0j9qDGeBwYZLCbjddeXS1SZBMY5
	ZqBAxCAMgvHEPfXDHkil/Um6lqM72z7EFUHGwwCEfcAu+l+zbAvjgabt+pHsGJu0hf
	e2tujXl/ICNs1HvkEjd1WoIj2PP2oQWQ50HPgQHo=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org BCE503858D20
Date:	Wed, 5 Feb 2025 16:56:29 +0100
To:	cygwin AT cygwin DOT com
Subject:	Re: |IO_REPARSE_TAG_MOUNTPOINT| (Junctions) not working for remote
	filesystems in Cygwin ?
Message-ID:	<Z6OKLXP-wTlVzYAb@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>
MIME-Version:	1.0
In-Reply-To:	<35e9e310-91d7-41e5-7e98-c1658030e912@jdrake.com>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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>
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>

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

- Raw text -