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

Re: Supporting non-XML-safe pathnames

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-11-24 22:06:22 CET

On Wed, 24 Nov 2004 kfogel@collab.net wrote:

> Marcus Rueckert <darix@web.de> writes:
> > > And because putting ^H in a file name is enormous fun:-)
> > or "\r" ;)
> > or "\n" ;)
> Note that we explicitly decided that "\n" in filenames was not allowed
> in Subversion (I don't know if we actually documented that, but I know
> we agreed on it in principle on this list a long, long time ago).
> This isn't so relevant for the current issue #1954 discussion, I'm
> just mentioning it because darix gave it as an example.
Why isn't it? \n is a control character. Ironically, it is accepted by

I am definitely with sussman here (his original proposal). I see no reason
at all to support control characters. I think it is a mistake of an OS to
support them in filenames, but that's another discussion. They are
problematic in our dump format (if I understand correctly), we have to
deal with them in the entries files, we'd have to deal with them in DAV
and probably have interop problems with other DAV implementations and they
confuse people. Currently, we have vugs in our support of real characters
outside of ASCII (small encoding bugs creep up now and then). I don't see
any reason at all to support these control characters whatsoever.

OTOH, as I point out in the issue, using svn_xml_is_xml_safe for this is
wrong. Currently, it doesn't accept UTF-8 outside of ASCII and it
accepts certain control chars. We need a new function to check if a path
is valid. It should accept valid UTF8 and reject control chars (0-0x1f,
0x7f, 0x80-0x9f) and possibly other non-Unicode characters.


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