Message-ID:	<3E39880C.4060607@mif.vu.lt>
Date:	Thu, 30 Jan 2003 21:16:12 +0100
From:	Laurynas Biveinis <laurynas DOT biveinis AT mif DOT vu DOT lt>
Organization:	VU MIF
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language:	lt, en, en-us
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com, Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
Subject:	Re: Take on __solve_symlinks()
References:	<3E286C07 DOT 7040200 AT mif DOT vu DOT lt> <3E2943DA DOT 523770FC AT phekda DOT freeserve DOT co DOT uk> <3E297258 DOT 50906 AT mif DOT vu DOT lt> <3E2A9396 DOT EF36FE73 AT phekda DOT freeserve DOT co DOT uk> <3E305DAB DOT 8090607 AT mif DOT vu DOT lt> <3E305D5A DOT 16693047 AT phekda DOT freeserve DOT co DOT uk> <3E386A1C DOT 9050303 AT mif DOT vu DOT lt> <3E3940F9 DOT A66C7217 AT phekda DOT freeserve DOT co DOT uk>
In-Reply-To:	<3E3940F9.A66C7217@phekda.freeserve.co.uk>
X-OriginalArrivalTime:	30 Jan 2003 19:13:07.0074 (UTC) FILETIME=[9EDBAE20:01C2C893]
Reply-To:	djgpp-workers AT delorie DOT com

Richard Dawe wrote:
> Test 3: Solving c:../../../../../../djgpp.204/tests/libc/compat/unistd/test1
> 
> __symlink_path:
> "c:../../../../../../djgpp.204/tests/libc/compat/unistd/test1"
> 
> __real_path:
> ""
> 
> I have plain CVS, plus these diff below. If I don't the diff below applied,
> then it looked like __real_path contained the result of the last
> __solve_symlinks call (__symlink_path ending with file1 instead of test1).

Very interesting, given that the first thing __solve_symlink does is to 
copy __symlink_path to __real_path. I don't see how this patch could 
make any difference, and it doesn't at my sandbox. The testcase gives 
correct results both ways. I strongly suspect that we are testing two 
different versions of __solve_symlinks... Maybe you could try copy 
somewhere the directory with testsuite sources, copy here up to the date 
CVS version of __solve_symlinks and add it to makefile ?

Secondly, the only potential point of failure in this testcase with 
current __solve_symlinks version is a call to 
__internal_readlink("c:../../../../../djgpp.204/tests/libc/compat/unistd/test1")
from the last repetition of main __solve_symlinks loop (with end pointer 
pointing at '\0'). This call works for me, it seems that 
__internal_readlink deals with too many /../../ correctly. Could you see 
what happens at your side (in the case we have identical 
__solve_symlinks() sources)

> Perhaps you could e-mail me your version of the xsymlink.c test sources?

Uhm, maybe after clearing up the first point above. Test sources keep 
changing there...

>>>Maybe the test "xsymlink" should take a drive specifier. It could then
>>>create a cross-drive symlink to any file on that disk. E.g. c:/temp/foo
>>>-> d:/whatever.
>>
>>BTW, I wonder if we could do something like SUBST does at runtime...
> 
> 
> What would you do, if we could?

Then we could create a virtual drive on the fly for the testsuite and 
destroy afterwards. No 'insert blank floppy' stuf...

--
Laurynas

- Raw text -