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

Supporting non-XML-safe pathnames

From: VK Sameer <sameer_at_collab.net>
Date: 2004-11-24 07:00:56 CET


This is a request for input regarding a general solution to issue 1954

1954 is about running svn_xml_is_xml_safe() on pathnames before
importing or adding them if they are not acceptable. A simple fix was to
add the check in libsvn_client/[commit.c and add.c], before adding the
pathname to the editor.

While testing the fix, I found out that Linux allows creation of
directories and files with control-characters in their names. The
problem now seems to be that Subversion doesn't support this, since an
un-encoded pathname can corrupt the entries file. Since Subversion
shouldn't limit the OS capabilities arbitrarily, Mike Pilato suggested
adding a base64 encode and decode at these points:
- writing to and reading from the entries file
- creating and parsing webDAV XML network requests/responses

The encoding/decoding process will be triggered only if the pathname
fails svn_xml_is_xml_safe(). For encoded paths, an attribute is then
recorded stating that the pathname has been encoded. Decoding takes
place only if that attribute exists.

Some issues:
  cmpilato: there is still a danger here though, in that there are
            certain webdav requests we don't "own"
  cmpilato: meaning, the DAV spec defines "you shall format your XML
            like so, and it shall validate against DTD foo."
  cmpilato: in those cases, we can't encode. and for those operations,
            folks might just be screwed.

- Windows doesn't seem to support such pathnames
  but then Subversion supports symlinks while Windows doesn't.

Are there any other issues to consider before taking a stab at it?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 24 07:02:03 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.