DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5169oZP92267965
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 5169oZP92267965
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=P+/4db4A
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 3C3C13858404
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1738835433;
	bh=vuDN6B0jTATfh/Kx/NV+gLUwsG7i+MVUjTWrkSgfDOo=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=P+/4db4AX5cpQl7ZsOgnLGU5y+kUvgVokj15xsj90OLzvRrhCX0e0dqR2CkbOJC2b
	jlmBZxprtxOKclQ0kP7lxN0xLN3kdGtHVEbkVBhdHY4mEDb3UWS/VHQOi8rHN2UoC8
	6a6Syv1yVqeo7Iuo2DoU4bNAi79v6pM+JTeOk9AA=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org D46D43858CD1
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org D46D43858CD1
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738835405; cv=none;
	b=WqIuG7ux5wLsu3ZJ8m9PMWm7+dHrYVebWINXjoFblOZM7zctDL3wPUPXm1mh6i7BZdtXagnOk3Q36zgaHbUuJc8FMHO4pHqULvjzh2aZjnZInb2auAQaA5Dq+dy/JOsskQC2vbirZIbWiPMV7Lcovu4NKh6Nj2Ft0msu5K71czI=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1738835405; c=relaxed/simple;
	bh=QdzUpcT3jkSlaNTN5+Tx0PnPHxwV/BPt6aRoqdctjgI=;
	h=DKIM-Signature:Date:From:Message-ID:To:Subject:MIME-Version;
	b=GjiWzBRsxZTEw6T750Y1fyMvdAAhEN16UI/sjUW4F3+EadbLQjOy6qy7m96S+Ad+k8oHfJ9q6Nq9TuPuIcEFXQNxSX4EIFjz2cPSRlhomaNg7bcxwUo0I0rUFD6ib1Xmt3N3XyScQSK7ZAVPvjLeLC+QLpsHVcIWjYztwc0HkI4=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org D46D43858CD1
X-Yandex-Fwd:	1
Date:	Thu, 6 Feb 2025 12:47:24 +0300
X-Mailer:	The Bat! (v9.3.4) Professional
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
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:	Andrey Repin via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Andrey Repin <anrdaemon AT yandex DOT ru>
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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 5169oZP92267965

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

- Raw text -