On Sat, May 11, 2013 at 04:31:52PM +0200, Stefan Fuhrmann wrote:
> 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).
Yes, that's pretty much what happened in the case I observed.
As detailed in the report, 'svnadmin verify' was able to spot the
corrupt node-rev entry, but wasn't able to spot the corrupt
changed-paths list.
> 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.
That's true. It depends on the case at hand. But 'svnadmin verify'
will hopefully spot the corrupt revision in any case (but see also
http://subversion.tigris.org/issues/show_bug.cgi?id=4343).
Received on 2013-05-11 16:43:23 CEST