X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 8AB903856DDA
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1659428457;
	bh=6m53lsIzbkVIrjVtXZJ6bCkCw2LoweJ6uEzhUx0A3Ok=;
	h=Date:From:To:Subject:References:In-Reply-To:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	Reply-To:From;
	b=of8ru2wUfs8jlLGiFiE3LuqMjAjQUXOpRNiAM+MONJ3O+PcR5PEdanG2pY61Cwnci
	mselAvZg65c/4E8/fjgnzbQ8sv4rwhVYzk1oNOgUId94gESPdbPR/M+isxbNJL+Lgd
	v8001sAPS6or/6+cE9wH44ZpEA7wrlyiPUVsqOoA=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 758883858D37
Authentication-Results:	sourceware.org;
	dmarc=fail (p=none dis=none) header.from=cygwin.com
Authentication-Results:	sourceware.org; spf=fail smtp.mailfrom=cygwin.com
Date:	Tue, 2 Aug 2022 10:19:43 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Issues with Cygwin64 on Windows11
Message-ID:	<YujeH0H3PJOPOGQ3@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<CAF9kqNEufMLALpfp-HwYaApoy=Y8ce2LBnD_YCY06YwEc_6guw AT mail DOT gmail DOT com>
	<20220731172132 DOT cf4d0a2d6acf2f6af96bb1c2 AT nifty DOT ne DOT jp>
	<20220801092349 DOT 860472b4da6f3a781eb3ffc4 AT nifty DOT ne DOT jp>
	<c9feffc3-a4e2-6419-2e80-10322f70cf49 AT cornell DOT edu>
	<20220802131217 DOT 5ad7aa040f25a9b4e9266979 AT nifty DOT ne DOT jp>
MIME-Version:	1.0
In-Reply-To:	<20220802131217.5ad7aa040f25a9b4e9266979@nifty.ne.jp>
X-Provags-ID:	V03:K1:OHhzs2HZry7qPh0uqWB8kQxXlnhBBOxETUsNvNoqJIuv0y8FcWk
	ZsHqL8tyLh5J1ISwSPRXsg1jL8Q/nJC4lBG2PlVDfZ544aBXj5f3oHgvrBhM/Un6+C4MgSe
	ERSXCXYka/Ot0UlppFpE0AJz80b0OjsGR3CuJM/3S8hkVkj39gN+PPamGH6iGol5GV5Dacn
	REhFJN2B3QYv1m4tYpTNQ==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:i46IfRbe4yY=:K0K+t7Ak6SPe4ygAxoBwX3
	IbC+eR0NyDoT6/KGra5eCczn787Ad9NaaqrASZxeMlzAbCkz5RbAl0MoxARoKdvf7kw7PZA75
	srZ58gOmogufcy/h7lL+qhyuBIon4Xx0RRRlKpJqJgypzmXWE64kXSBpwd2OT81NG8IXtikxV
	mWmHkvxXrAV5oYB0N1iBzEoj7h9yB8BDtkSQswpzZzolHBMINZO2SfKUtyLpUghjjqy2VAzoT
	n4a9/+r6/9IA7LRXpgsWvbkwyWxjPnn9TO/KxBfpKD4UtflqA0OQG7Ibqi2R41+4QFERURP87
	4KDFVcDT7tyiVMqWqbVW6hYMJbCjxc9QyjorjCRR3asoNBcXX2h9fXYFZa3vk7uz5aGkz1S/1
	DGFB2WCJxzVibBGLuojie0Cd0pLGA4kItsidRPHGMiUr/TXxpceNr2QYWr0AoEeXL/YFnPnqa
	WAqFYExxuIrK+3mWVuVV7xNaWgmTC/dChIlXkUVdW5Q9tbum5QlhHZqmM0oEMjysEqlMlo5tD
	xBT1RuKFglTA0QhYa6uP5S/AcoNWO/46mUCe42537UsCjyB1aWkfng1NQjov1D+eyqD28/w/B
	tNKYF8RqI9C2zbQazPVocYDZuRWmzTjFnOF6l3rhklZZM8PFM0qEPyKgwpWI8Fuda4S6DtYm4
	TCRiQ4+GvyU9Qh6DPXHXI786+u7EcWSfS2g93/afa3hXi6S2HMUGHXW0tEJG+s5tv5x0SDRVE
	oQVKuALQlW5P4QvSQdn01oxL76W21Q4NyZaJiNx1KFS36PpwWbLU1UuaQ3o=
X-Spam-Status:	No, score=-101.4 required=5.0 tests=BAYES_00, GIT_PATCH_0,
	GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_NUMSUBJECT,
	RCVD_IN_MSPIKE_H2, SPF_FAIL, SPF_HELO_NONE,
	TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
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>
Reply-To:	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 Aug  2 13:12, Takashi Yano wrote:
> On Mon, 1 Aug 2022 21:14:52 -0400
> Ken Brown wrote:
> > On 7/31/2022 8:23 PM, Takashi Yano wrote:
> > > On Sun, 31 Jul 2022 17:21:32 +0900
> > > Takashi Yano wrote:
> > >> On Sun, 31 Jul 2022 09:11:17 +0300
> > >> Dimax wrote:
> > >>> $ ln -s /cygdrive/C/XOL/ work
> > >>> $ ls -all work
> > >>> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
> > >>> $ cd ~/work/
> > >>> -bash: cd: /home/Alex/work/: No such file or directory
> > >>>
> > >> Thanks for the report. This seems to happen only when
> > >> the drive letter is uppercase.
> > >>
> > >> ln -s /cygdrive/c/XOL/ work
> > >> works.
> > >>
> > >> Anyway, I think this is a problem of cygwin1.dll.
> > >> [...]
> > > I found the patch attached solves the issue.
> > > 
> > > Corinna, WDYT?
> > 
> > I'm not Corinna, but replacing oldpath by normpath doesn't seem like
> > the right thing to do at the time of symlink creation.  If I create
> > a symlink under Cygwin, I expect the target to be used under Cygwin
> > exactly as I enter it.

Apart from the normalized mnt prefix, that's right.

> Hmm, that's the point.
> 
> > The internal replacement of the cygdrive prefix by /mnt for WSL
> > compatibility is fine, as long as I never see it except under WSL.
> > But since WSL doesn't recognize /mnt/<uppercase drive letter>, I
> > don't think Cygwin should convert /<cygdrive prefix>/<uppercase
> > drive letter>.  Users who want WSL interoperability just have to use
> > lowercase drive letters.

Yes, I agree.  I'm surprised anyway that somebody is using uppercase
drive letters voluntarily.

> Then, what about the v2 patch attached?

symlink_wsl is doing the right thing, as Ken points out.  I think, the
solution is not to change symlink creation but rather symlink
evaluation.  Locally I applied the below patch and fixed the issue:

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index ea695ed997b4..6b519d0bbe2d 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2651,7 +2651,7 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
 		}
 	      rp->ReparseDataLength = path_len + sizeof (DWORD);
 	    }
-	  else if (islower (path_buf[drv_prefix_len + 1])
+	  else if (isalpha (path_buf[drv_prefix_len + 1])
 		   && (path_len == drv_prefix_len + 2
 		       || path_buf[drv_prefix_len + 2] == '/'))
 	    {

This does not fix cases like /cygdrive/./c or something like that,
but I wonder if we really have to handle them...?

The idea was to convert /mnt into the cygdrive prefix only if this is a
cygdrive path and not to touch /mnt if it's a user generated path.

Therefore, the more effort the code makes to be clever, the higher
chances are that an incorrect conversion takes place.

Having said that, of course, we could change check_reparse_point_target
to handle multiple slashes or dot path components, kind of like the
below...

...but the point of discussion is, how much effort do we want to
put into this?

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index ea695ed997b4..c7f743b3c7bf 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2628,7 +2628,7 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
       char *path_buf = rpl->LxSymlinkReparseBuffer.PathBuffer;
       DWORD path_len = rpl->ReparseDataLength - sizeof (DWORD);
       bool full_path = false;
-      const size_t drv_prefix_len = strlen ("/mnt");
+      size_t drv_prefix_len = 4; /* strlen ("/mnt") */
       PBYTE utf16_ptr;
       PWCHAR utf16_buf;
       int utf16_bufsize;
@@ -2651,15 +2651,30 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
 		}
 	      rp->ReparseDataLength = path_len + sizeof (DWORD);
 	    }
-	  else if (islower (path_buf[drv_prefix_len + 1])
+	  else
+	    {
+	      /* Skip multiple slashes and "." path components between
+	         /mnt prefix and the drive letter. */
+	      while (true)
+		{
+		  if (path_buf[drv_prefix_len + 1] == '/')
+		    ++drv_prefix_len;
+		  else if (path_buf[drv_prefix_len + 1] == '.'
+			   && path_buf[drv_prefix_len + 2] == '/')
+		    drv_prefix_len += 2;
+		  else
+		    break;
+		}
+	      if (isalpha (path_buf[drv_prefix_len + 1])
 		   && (path_len == drv_prefix_len + 2
 		       || path_buf[drv_prefix_len + 2] == '/'))
-	    {
-	      /* Skip forward to the slash leading the drive letter.
-		 That leaves room for adding the colon. */
-	      path_buf += drv_prefix_len;
-	      path_len -= drv_prefix_len;
-	      full_path = true;
+		{
+		  /* Skip forward to the slash leading the drive letter.
+		     That leaves room for adding the colon. */
+		  path_buf += drv_prefix_len;
+		  path_len -= drv_prefix_len;
+		  full_path = true;
+		}
 	    }
 	}
       /* Compute buffer for path converted to UTF-16. */

> > I'm tempted to go even further and say that Cygwin shouldn't ever
> > convert the cygdrive prefix to /mnt, on the grounds that users who
> > care about WSL interoperability can simply use /mnt as their
> > cygdrive prefix.  But maybe that ship has sailed.

In hindsight this might have been a step too far.  I was trying to allow
interoperability and reduce the number of problems based on different
drive letter handling.  And, well, this is the first time a user has
a problem due to that :}

The ship hasn't sailed entirely.  We can revert this decision for 3.4
and just keep the /mnt conversion in check_reparse_point_target for
backward compat.  Or we just fix the problem at hand and otherwise
keep the code as is...?


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

- Raw text -