DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=Muf4xNx/90w68xV9xBK1xtmQyJ7zDuo5By5C6yt8DkiFBCZei3R1c
	hmJQ0PSfsHvoyPRsvlgq0hloHNilK6Dk2a2v5YZ8KPApfo6kLpIJH9P8gta9nMea
	hMvuuW/KG9BwtNK0sgENE3ARxzzW3KxWESJT9wS2pZnm4NqXeU2m/8=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Mon, 20 Apr 2015 11:31:15 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Is there a way to make an existing UNC symbolic link behave like a mount point?
Message-ID: <20150420093115.GP3657@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <CAGV6pnn_P1UNUXVW8sf1t==KePrxFUsW6JZrmQ2CrjZW0ce2yA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="6cCUF33RYdKJBOlz"
Content-Disposition: inline
In-Reply-To: <CAGV6pnn_P1UNUXVW8sf1t==KePrxFUsW6JZrmQ2CrjZW0ce2yA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

--6cCUF33RYdKJBOlz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 19 14:16, Skarr Socrates wrote:
> Hi all,
> I am experiencing problems with a UNC symbolic link and how it is
> interpreted by cygwin. The issue is as below:
> [...]
> However,
> bob@machinea /cygdrive/c/Users/bob $ touch file.txt
> bob@machinea /cygdrive/c/Users/bob/bsdhome $ cd bsdhome
> bob@machinea /cygdrive/c/Users/bob/bsdhome $ cp ../file.txt .
> cp: cannot stat =E2=80=98../file.txt=E2=80=99: No such file or directory
> [...]
> I understand the symptoms but I have no clue how to make this work or
> if this is a feature or a bug. Is this related to the virtual
> directory? can it be disabled?

No.  This is a long standing misbehaviour of Cygwin.  The problem is in
the core path handling routine, which evaluates paths from tail to head
component rather than vice versa, as required by POSIX.

The original authors probably implemented it this way for speed, and the
drawbacks (as above) were only found much later.

Why did we never changed that?  Because the core path handling routines
are long-winded, complicated, and probably the most crucial part of the
DLL.  Nobody dared to rip it apart yet, but that's what would be
required.

I'm sorry if that doesn't help you, but that's as it is right now,
unfortunately.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--6cCUF33RYdKJBOlz
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVNMdjAAoJEPU2Bp2uRE+goJMQAIRN0mhH0OALqipVyZNL8oL1
UpD5WfYGzgsClgtWHO9tyjvNym465HtRrlwuSZyO7X7HdQV49e3LZHnjSp3Etjvn
ltZcFiMOi85q9KGkgXcxQcRMlcSh8lXtfWU58eOWgqZsXFk+/IpU/E0Vkao9WCHZ
A2pQ5I/MTvvjFyj3vM+pmZshIXF0Z6ONAAiz47VU/mXncpCz9lhk/BVgrobtoja+
Y7fKU/7e+3Ic9hDWsMPAobpHakp1qPmhbvgUnhOMTY1lYINdgV0zCRTj6GB+QadS
CXHVgnZ+twqcwY51jG0ER/c/p67OAnUTHT3ra/qoBDGqo0hnAtVsDw5niVfW3j3p
EuXSZy7eNKnZnoz83cMgCDUrWva8YArl+u96UQxxbEpseXkBVat79e8N7dhBAigD
JkoFtsO/ZSZFD21fC1eF4Hc+o6DVHfSKKJFyTtEmExwZ5pN2Jcb2HVsGMthxwDUN
tFolyjQ0u4ZkVhUHKXSEybrP33MPqSTGrS7XCXpjR2SP0g4x4qwVADlNimCo1X40
tVmJTecyRkyO03uyRlOfB3FAelNQ/F/myPY5mgC797zwnJp9GSjq0kHRRD+R4S0D
OkBt/lp4+imx+wOhGJwamplsAhkAqIcxMWWfvEiOd/qUQC4elfM/YnIaL+SPvG7p
VLquHQyxMKE5sBMVaohA
=EcUF
-----END PGP SIGNATURE-----

--6cCUF33RYdKJBOlz--