Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

[Andrey Repin <anrdaemon@yandex.ru>]

Greetings, Corinna Vinschen!

> On Feb  1 15:47, Andrey Repin wrote:
>> Greetings, BRISLANE Mark!
>> 
>> > We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but
>> > perhaps our scenario is slightly different because it's still happening.
>> > SERVER1 has a folder on D: called folder 1, which is a symlink to
>> > "\\server2\share\folder1" - created with mklink /D folder1 \\server2\share\folder1
>> 
>> > DOMAIN+Administrator@SERVER1 /cygdrive/d
>> > $ ls -l
>> > total 3
>> > drwxr-x---+ 1 Administrators SERVER1+None     0 Jan 28 11:03 '$RECYCLE.BIN'
>> > d---rwx---+ 1 Administrators SYSTEM                0 Jan 25 23:07 'System Volume Information'
>> > lrwxrwxrwx  1 Administrators DOMAIN+Domain Users   32 Nov  9 10:52  folder1 -> //server2/share/folder1
>> 
>> > DOMAIN+Administrator@SERVER1 /cygdrive/d
>> > $ cd folder1
>> 
>> > DOMAIN+Administrator@SERVER1 /cygdrive/d/folder1
>> > $ cmd
>> > '\\server2\share\folder1'
>> > CMD.EXE was started with the above path as the current directory.
>> > UNC paths are not supported.  Defaulting to Windows directory.
>> > Microsoft Windows [Version 10.0.14393]
>> > (c) 2016 Microsoft Corporation. All rights reserved.
>> 
>> > C:\Windows>
>> 
>> > This used to work in older versions of Cygwin.
>> 
>> The interesting part is that the behavior is dependent on sequence of events.
>> 
>> `mintty bash -i` in a directory:
>> 
>> > $ pwd
>> > /cygdrive/d/cygwin
>> > $ cmd
>> > Microsoft Windows [Version 6.1.7601]
>> > Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>> >
>> > D:\cygwin> exit

> Not sure how you did that,

Did what? Opened an interactive shell in a directory? Navigated into it in a
different file manager and just used a command.
Opened CMD in an UNC path?

reg ADD "HKCU\\Software\\Microsoft\\Command Processor" /f /v "DisableUNCCheck" /t REG_DWORD /d 1

Not even required to re-login.
Or globally for entire system in HKLM\SOFTWARE\Microsoft\Command Processor
(keep in mind there's 32- and 64-bit variants of the key, you'd have to modify
both to get consistent behavior).

> but I can't reproduce this, and I'm pretty certain the CMD failure is how
> Cygwin works for a long time.  I get this same behaviour back to Cygwin
> 3.1.7, which is where I stopped testing.

Win10 this time:

anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ pwd
/mnt/d/Reserv/test/cygwin
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ cmd
Microsoft Windows [Version 10.0.19044.1466]
(c) Microsoft Corporation. All rights reserved.

D:\Reserv\test\cygwin>exit
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ cd $( pwd )
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ pwd
/mnt/d/Reserv/test/cygwin
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ cmd
'\\DAEMON1.DARKDRAGON.LAN\arc\cygwin'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Microsoft Windows [Version 10.0.19044.1466]
(c) Microsoft Corporation. All rights reserved.

C:\Windows>exit

## Here I fixed the CMD settings in a different elevated window

anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ cmd
Microsoft Windows [Version 10.0.19044.1466]
(c) Microsoft Corporation. All rights reserved.

\\DAEMON1.DARKDRAGON.LAN\arc\cygwin>exit
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$

> The reason is this:

> Reparse points created with mklink /d are evaluated as symlinks. This
> reparse point contains an absolute UNC path.  If you cd to this dir in
> Cygwin, Cygwin evaluates the path and reads the symlink content.  Given
> the content is an absolute path, the symlink content replaces the
> entire path.  Internally the CWD is stored twice, once in POSIX, once
> in Windows syntax.  In short, what happens is this:

>   pwd           ->      POSIX(/cygdrive/d), WIN(D:)
>   cd cygwin     ->      
>     open reparse point "cygwin"
>     read content == "\\server2\share\folder1"
>     convert to POSIX == "//server2/share/folder1"
>     restart path evaluation and check for further symlinks
>     -> no further symlinks
>     convert path to Windows == "\\server2\share\folder1"
>     store both paths as new CWD
>   pwd           ->      POSIX(//server2/share/folder1),
>                         WIN(\\server2\share\folder1)

> So what happens in bash?

>   $ pwd
>   /cygdrive/d
>   $ cd cygwin
>   $ pwd
>   /cygdrive/d/cygwin
>   $ /bin/pwd
>   //server2/share/folder1

Except if you don't "cd", it uses whatever is given by the operating system.

anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ pwd.exe
/mnt/d/Reserv/test/cygwin
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ cd $(pwd)
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$ pwd.exe
//DAEMON1.DARKDRAGON.LAN/arc/cygwin
anrdaemon@Daemon-EC:xterm:/mnt/d/Reserv/test/cygwin
$

> pwd is a builtin command.  It works differently from /bin/pwd in that
> bash pwd does not cd to a dir and then reads the dir stored in the OS
> again.  Rather it just appends the new dir as has been given on the CLI.
> There's a setting somewhere to make bash reevaluate the CWD all the time
> but I don't know it off the top of my head.

> Bottom line is, that *in fact* the CWD in the underlying Cygwin layer is
> the share, not the drive letter path.  And that's what any subsequently
> started process gets as CWD, CMD just as well as any Cygwin process.

> If you want CMD to succeed in this scenario all the time, you have to
> start CMD in /cygdrive/d and then pushd or cd to the cygwin dir.  CMD
> will not evaluate the reparse point as symlink and just go ahead.

> Alternatively, just use powershell if you need a native shell.  Powershell
> has no problem with UNC paths as CWD.

> I hope that explains it sufficiently.

I though, by the time everybody had learned to suppress that stupid CMD
behavior, but here it is once again.


-- 
With best regards,
Andrey Repin
Thursday, February 3, 2022 11:40:48

Sorry for my terrible english...