X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 28BA7383F422
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1643726128;
	bh=nlSOtLsR9hJqkhdOa6Ugv1di4uwNQ/x0iovE4X1aw20=;
	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=y097Aj0BmO93Ett88j/kduyAAF0fhW78kyZd5BTCRN7Cu+UH+JLM0bGDhs4H+tU3+
	IMjSJRFOTNmhEMpSipvNyICSi+ko08n6BoSUhf2gw2tXHUV1awmJwsdqXLUwJiVvQ2
	ZXgGd93PoR/RzF9NZ9djpvU2IHl9aQDndG5buZac=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 86C40385E82A
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, 1 Feb 2022 15:34:14 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work
Message-ID:	<YflE5ljqQxvwdNZA@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<VI1PR04MB41575EBC7E202ACC1249553186269 AT VI1PR04MB4157 DOT eurprd04 DOT prod DOT outlook DOT com>
	<1157721958 DOT 20220201154725 AT yandex DOT ru>
MIME-Version:	1.0
In-Reply-To:	<1157721958.20220201154725@yandex.ru>
X-Provags-ID:	V03:K1:TuPcsKnjkkSPFIxFypJMj+ytfpghRi1zTjYV4Js8zM9utAI82/Q
	PiuOk2QCtsIVcOR+/UDBkTY4e+zH5WEceVFBsk8fnBY46ZE8RxA5x0iAcSLPNg9gOWmWtkW
	rVEH7OYXG1LbAMV8uzTrppNbf0h8lsH8hWACVtF4e9P6rjE3a9DV+kBSs1b7RGH3GcYS3cS
	MzCUqiG6EAWyiju8dya2w==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:0ePqWWK1k4w=:UOltDJCs75tozr/hjl1xYv
	Awu64M5gi/T8cf0dXj9CQbVt4LqNuw/YHN4bYT4YLVns2gkuGu6bQ2YaeCptceH0SRi/Wf8xW
	5q7Iqvkp2gZZD9smabkJ/FMfGubxFFg4vN+Ig+nmP0KEIsLHasFzuvLrtuYCM0OISo/X5DxDV
	lFB9GATMxUcsZ4KHAlnjCcwFsNSN73AikNTsQDilzPiBKpPPUeW9RJtfU6ZtwfmvPTcgQj3VW
	5dXCL8P3HUZCmppU6RVP5FdwHfMsE8YYLZhGY+In3Z1m6ICRjnLGK3tQimZnU/8Wbm8LIuOvu
	VNJEpvZ+LZDkVUhHeNPyopsNAoOHFKBE3MnShQluLx5VM+fqqxGbwN78x0f2E6HuUVFpXH6aO
	bjS9PaoCp4N7Rp5XWYGrHq82RtBngFgdyM9mBa278uGuZlveclE7pI3Ki00+McH5RhlT3vL4r
	u1cwmCTmLXcUCHJwTnvlW0APBkG05BXizGlpzm85j81xzBtJRCMQ/GzQVh7AQhCuNolsxOZfn
	FrOpcvTQ/wKlBRTEW2gtmeBFCrqXPHdzYJsgibWQyi0obCmv6HThRpSIThqGwPYLbFansq6MD
	d0jleu4/pZ82HhxEEuqu8FtIaacjMErMDGWH7ns+cFhSZ52CVSl7vPWa4+6Y3m+vtZoeec8UJ
	FjFqwUPXWxpyDZG4DHXJzUXKp1y8u5ll9j31VLbAutXDe9RyVkq54B3yEBxLKbjwiVtebFkuQ
	W3fl2dBclfT3wSBU
X-Spam-Status:	No, score=-97.1 required=5.0 tests=BAYES_00,
	GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_FAIL, SPF_HELO_NONE, TXREP,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version:	SpamAssassin 3.4.4 (2020-01-24) 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 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 AT 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 AT SERVER1 /cygdrive/d
> > $ cd folder1
> 
> > DOMAIN+Administrator AT 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

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