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

Re: forbidding control characters prohibition in libsvn_repos in 1.7.10 (issue #4340)

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Sat, 11 May 2013 16:31:52 +0200

On Sat, May 11, 2013 at 3:24 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> On Sat, May 11, 2013 at 03:13:30PM +0200, Stefan Fuhrmann wrote:
> > You may have gotten lucky
> > if the newline was at the very end of the path,
> No, not at all. See the original problem report which was about
> such a case: http://svn.haxx.se/dev/archive-2013-03/0415.shtml

First off, I'm +1 on fixing that in 1.7.x.

But you omitted my astrology reference in the citation.
FSFS stores paths in noderev records and changed path
lists. The respective parsers are somewhat forgiving:

* Empty lines at the end of change path lists get ignored
* Changed path lists will only be read for "loggy" (log, merge)
  and "dumpy" (dump, verify) operations. They are not
  required for e.g. checkouts.
* The path element in a noderev record is the last mandatory
  one - the following copyfrom and minfo-* props are optional.
  The parser will simply stop at a newline.

So, committing file paths that end with a newline and
with just one file / rev, chances are that the corruption
will only surface in an inconsistent path name (reported
w/o newline by change lists and noderev but seen with
newline in the directory entry).

Getting newlines at the end of a file name is most likely
due to some automated process / script not properly
splitting its input stream. And those workflows might
accomplish their goals despite corrupting the repo.

-- Stefan^2.

*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
Received on 2013-05-11 16:32:25 CEST

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.