X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=Kwf/FHSofeMA23dO35/zOuHELtYhsYlirT0Jb2Unrga
	qN0CPbt0HRWdhMR/nDiCkVAtx5Q13vBYa/1d867BclQGdXADFSTZy7AJLmh7+iZY
	rq+Svr8h+ePwX+uNE83BfwVUzDrZsAniYIO2viN9w3nXO79yxsSNBxC/HrSaMh9c
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=5rjCDIqdo0ETqYH3KNPQeHRKzGc=; b=IK4P76G9nMokHKzjE
	lEblElMQznLkWuC+GmVJRYgS6y11OXUDEiFti95Og4CRVi8TM5UyNadZrsVFCs+n
	yDBkfJPEn81dX/7V4MQvnASxiPx7HqaMkwRESxybTgnOFYhDjMTMcYiVzjVsLOTj
	2vcnv7rqqN3UwGolq8Bvid4HiE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.3.2
X-HELO: rtits2.realtek.com
X-SpamFilter-By: BOX Solutions SpamTrap 5.39 with qID s4Q6jBJX014727, This message is accepted by code: ctloc85258
Message-ID: <5382E2F8.8040407@realsil.com.cn>
Date: Mon, 26 May 2014 14:45:12 +0800
From: Robert Bu <robert_bu AT realsil DOT com DOT cn>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: x86_64 Cygwin 1.7.29: possible bug to trace symlink (Win7)
References: <0BA358A6A1AD484EA0BECE9A36AA31753D6F7D00 AT rsex2 DOT realsil DOT com DOT cn> <0BA358A6A1AD484EA0BECE9A36AA31753D6FCBC2 AT rsex2 DOT realsil DOT com DOT cn> <0BA358A6A1AD484EA0BECE9A36AA31753D6FFE94 AT rsex2 DOT realsil DOT com DOT cn> <0BA358A6A1AD484EA0BECE9A36AA31753D70AFC2 AT rsex2 DOT realsil DOT com DOT cn> <0BA358A6A1AD484EA0BECE9A36AA31753D70B096 AT rsex2 DOT realsil DOT com DOT cn>
In-Reply-To: <0BA358A6A1AD484EA0BECE9A36AA31753D70B096@rsex2.realsil.com.cn>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

-----Original Message-----
From: Robert Bu
Sent: 2014/4/21 9:59 +0800
>> On Apr 16 17:47, Corinna Vinschen wrote:
>>    > > Below is what I get:
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>uname -a
>>    > > CYGWIN_NT-6.1 RS-I9E3U8R4 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64
>> Cygwin
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>echo $CYGWIN
>>    > > winsymlinks:nativestrict
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>echo test > test.txt
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>mkdir dest
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>cd dest
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink/dest]>ln -s ../test.txt test.txt
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink/dest]>cd ../
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>mkdir src
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>cd src
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink/src]>ln -s ../dest dest
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink/src]>cd ../
>>    > > RS-I9E3U8R4:[~/tmp/test_symlink]>cat src/dest/test.txt
>>    > > cat: src/dest/test.txt: No such file or directory
>>    >
>>    > I can reproduce it now.  I made a mistake when creating the symlinks
>>    > the first time, which is, I created them with tcsh.  Tcsh tends to
>>    > change relative paths using ".." components to absolute paths on the
>>    > command line.  Using plain relative paths, I now see what's going on.
>>    >
>>    > But it'sa tricky problem.  I don't know how to fix it yet.  I'll
>>    > have to think about it, so please be patient.
>>
>> This is a very interesting problem which (again) shows the downsides of
>> the Cygwin path handling, namely the evaluation of the path from right
>> to left, contrary to what POSIX demands.  We really have to rewrite this
>> code, but that's a lot of work for long and dark winter nights and days,
>> not something we can do out of the blue.
>>
>> Therefore, I created a workaround within the constraints of the current
>> code.  Please try the today's snapshot from http://cygwin.com/snapshots/,
>> it contains my workaround.
>>
> This snapshots works as expected.
>
>> Note that in the current configuration we're having a recursion problem.
>> If your path consists of more than 15 native symlinks, all of which have
>> a ".." path component in the symlink target path, the result will be a
>> "no such file or directory" again.  This is pretty unlikely in normal
>> life, but can be easily constructed, of course.
>>
>
> There are about 10 native symlinks in the repo created git directory. So
> this workaround works for me for now.
>
> Thank you very much.
>
> Regards
> Robert
>
> .
>
Hi,

I get this problem again in 1.7.30 (x86_64) on Win7.
I think the snapshot "cygwin1-20140418-x64.dll" already fixed this problem.

Best regards.
Robert Bu



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple