Cygwin 3.3.4 - cmd to symlinked path doesn't work

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

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

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.


Corinna