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