Ben Reser wrote:
> On Sun, Jul 04, 2004 at 11:57:24AM -0400, Josh Pieper wrote:
> > Ok, in IRC ghudson proposed:
> >
> > <ghudson> Well, I'd agree with your initial judgement that we
> > shouldn't be collapsing .. segments, and then if we changed the
> > apr_filepath_merge() call in opt.c to an svn_path_canonicalize, we'd
> > fix the case I mentioned was broken.
> >
> > 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.
>
> No we sure didn't. But if we remove the colapsing of .. in paths we
> still need it in URLs. See the comment by Klaus Rennecke about the
> weirdness that occurs with URLS with /../ in them.
file:/// URLs would have to be special cased then to leave the ".."
path elements in since a portion is directly translated to a
filesystem path.
> The other option is to simply reject URLs with /../ in them. But
> whatever we do we need to make sure people don't get unexpected behavior
> with them.
That seems like an unnecessary restriction, especially for file:///
URLs. Are there other cases where this problem can arise besides a
repos->repos copy? If not, then maybe we could just not collapse the
".." anywhere and give better diagnostics there.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 4 19:28:43 2004