public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: Issues with Cygwin64 on Windows11
Date: Tue, 2 Aug 2022 13:12:17 +0900	[thread overview]
Message-ID: <20220802131217.5ad7aa040f25a9b4e9266979@nifty.ne.jp> (raw)
In-Reply-To: <c9feffc3-a4e2-6419-2e80-10322f70cf49@cornell.edu>

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

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:
> >>> Hello.
> >>> I've never had much luck with Cygwin64 and used the 32 bit version before.
> >>> Today I have no choice and I've installed Cyg64 on my new Win11 PC.
> >>>
> >>> Here is the first major issue I faced. I can not create symbolic links:
> >>>
> >>> Alex@Alexo ~
> >>> $ ls /cygdrive/C/XOL/
> >>>
> >>> Alex@Alexo ~
> >>> $ ln -s /cygdrive/C/XOL/ work
> >>>
> >>> Alex@Alexo ~
> >>> $ ls -all work
> >>> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
> >>>
> >>> Alex@Alexo ~
> >>> $ cd ~/work/
> >>> -bash: cd: /home/Alex/work/: No such file or directory
> >>>
> >>> The link is created but I can not use it.
> >>> The only thing that I did not standard was to call installation folder
> >>> C:\Cygwin instead of default C:\Cygwin64
> >>>
> >>> Any help would be highly appreciated.
> >>
> >> 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.
> >>
> >> This
> >> work -> /mnt/C/XOL/
> >> should be
> >> work -> /cygdrive/C/XOL/
> >> shouldn't it?
> >>
> >> It guess this is a bug in the code added for WSL
> >> compatibility.
> > 
> > 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.  The 

Hmm, that's the point.

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

Then, what about the v2 patch attached?

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

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: v2-0001-Cygwin-path-Make-some-symlinks-to-cygdrive-work.patch --]
[-- Type: text/plain, Size: 1389 bytes --]

From a190186c07449c7f9d08a13c26b87cad3f270a33 Mon Sep 17 00:00:00 2001
From: Takashi Yano <takashi.yano@nifty.ne.jp>
Date: Mon, 1 Aug 2022 09:02:23 +0900
Subject: [PATCH v2] Cygwin: path: Make some symlinks to /cygdrive/* work.

- Previously, some symbolic links to /cygdrive/* (/cygdrive/C,
  /cygdrive/./c, /cygdrive//c, etc.) did not work. This patch fixes
  the issue.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251994.html
---
 winsup/cygwin/path.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index eceafbbcf..c5ceb1da4 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1929,7 +1929,11 @@ symlink_wsl (const char *oldpath, path_conv &win32_newpath)
      cygdrive prefix is not "/", otherwise suffer random "/mnt" symlinks... */
   if (mount_table->cygdrive_len > 1
       && path_prefix_p (mount_table->cygdrive, oldpath,
-			mount_table->cygdrive_len, false))
+			mount_table->cygdrive_len, false)
+      && (strlen (oldpath + mount_table->cygdrive_len - 1) < 2
+	  || (islower (oldpath[mount_table->cygdrive_len])
+	      && (oldpath[mount_table->cygdrive_len + 1] == '/'
+		  || oldpath[mount_table->cygdrive_len + 1] == '\0'))))
     stpcpy (stpcpy (path_buf, "/mnt"),
 	    oldpath + mount_table->cygdrive_len - 1);
   else
-- 
2.37.1


  reply	other threads:[~2022-08-02  4:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-31  6:11 Dimax
2022-07-31  8:21 ` Takashi Yano
2022-08-01  0:23   ` Takashi Yano
2022-08-02  1:14     ` Ken Brown
2022-08-02  4:12       ` Takashi Yano [this message]
2022-08-02  8:19         ` Corinna Vinschen
2022-08-02 13:57           ` Ken Brown
2022-08-02 14:36             ` Corinna Vinschen
2022-08-02 14:39               ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220802131217.5ad7aa040f25a9b4e9266979@nifty.ne.jp \
    --to=takashi.yano@nifty.ne.jp \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).