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

Re: "Malformed XML" (l10n?) problems on checkout

From: <kfogel_at_collab.net>
Date: 2005-02-16 22:22:33 CET

"Dale Worley" <dworley@pingtel.com> writes:
> > From: Charles Bailey [mailto:bailey@newman.upenn.edu]
> > Sure. I think I've got it. By process of elimination, the
> > offending file
> > seems to be one named '.ooo^H^H^Htestff^Hile' (where ^H is
> > the usual \x08
> > backspace character). (No, I've no idea why the creator of
> > this file --
> > likely OpenOffice.org -- chose to use this name.)
> *Why* that file name exists is clear -- someone was trying to type a file
> name into a box. He typed ".ooo", and then decided he didn't like that, so
> he typed ^H three times, which moved the cursor back three spaces, then he
> typed "test", which wrote over the offending "ooo", but didn't actually
> remove them from the program's input buffer. Similarly, the final ^H was to
> correct the second "f" so he could replace it with "i". The name he thought
> he was getting was ".testfile".
> But you've identified the Subversion problem correctly -- a file name can
> contain "non-printable" characters, which are forbidden in XML. Worse, what
> you might think is a valid escape sequence to represent it -- &8; -- is also
> forbidden in XML, because "character entities" are forbidden from
> representing non-printable characters. See the discussion in
> http://www.w3c.org/TR/2004/REC-xml-20040204/#dt-charref
> Subversion may need to extend XML to allow this (and has to verify that its
> XML parser can deal with it).

Thanks for the analysis and the reference, Dale. You're right, and
Subversion's way of dealing with this is that (now) it no longer
permits such paths in the repository. See issue #1954, and see r12581
and r12632. There is a long thread on the topic, linked to from the
issue I believe, that explains the reasoning behind the decision.

So Charles, your solution right now is to rename that file in the
repository (perhaps even via dump/transform/load, so it's fixed in
history, if that's feasible for your team). Future versions of
Subversion won't allow that path to be in the repository in the first

Hope this helps,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 16 22:42:00 2005

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.