[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r10133 - in trunk/subversion: include libsvn_subr tests/clients/cmdline tests/libsvn_subr

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-07-04 18:30:31 CEST

Josh Pieper wrote:

>Branko ??ibej wrote:
>
>
>>Josh Pieper wrote:
>>
>>
>>
>>>I don't believe we considered the symlink case when breser and I
>>>initially talked on IRC about supporting collapsing "/../" elements.
>>>Does anyone have objections to just removing the ".." collapsing
>>>support from svn_path_canonicalize? That would also resolve the issue
>>>of implementing svn_path_canonicalize in terms of apr_filepath_merge.
>>>
>>>
>>>
>>>
>>The Unix filesystem interprets /../ sequences in paths _before_
>>expanding symbolic links. Try this:
>>
>> $ mkdir -p A/B/C/D
>> $ mkdir D
>> $ ln -s A/B/C/D d
>> $ cd d/../D
>>
>>Guess where you'll end up?
>>
>>So, this whole discussion seems pointless.
>>
>>
>
>
>Actually my linux system lets you resolve files in either parent.
>There are certainly cases when it works.
>
>Try this recipe:
>
>mkdir -p A/B/C/D
>echo "foo" > A/B/C/foo
>ln -s A/B/C/D d1
>cat d/../foo
>
>
So. Looks like the shell and the filesystem behave differently. This is
really boring, because it means we'd have to canonicalise paths
differently on Unix and Windows, which again points at apr_filepath_merge.

Hm. Weird.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 4 18:32:45 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.