Max Bowsher wrote:
>Corruption in the texts of files is not detected by "svnadmin verify".
>
>Also, "svnadmin recover" can sometimes cause problems to appear!
>
>Make a repository. Commit a file. Edit the "strings" db by changing some
>characters.
>"svnadmin verify" passes! "svnadmin dump" dumps the correct version!
>
>
The "current" data is probably still being read from the log files.
>"svnadmin recover". Recovery succeeds, but *now* "svnadmin dump" fails with
>checksum errors!
>
To be expected, if the log file is no longer there (or no longer marked
"current")
> And "svnadmin verify" is *still* passing!
>
>
Now _that's_ weird.
>So, there are 2 issues.
>
>1) "svnadmin verify" needs to actually read file contents, even though it
>doesn't output it.
>
>
In fact, "svnadmin verify" does its best to do read the contents, since
it calls svn_repos_dump_fs. However, there's a bug in
libsvn_repos/dump.c near the end of dump_node(); if the output stream is
NULL (as it is in this case), the file contents are never read. Instead,
they should always be read, and svn_stream_copy should be relied upon to
not try to write to (or read from) a null stream.
Another way to fix this without propagating the NULL-stream exception
all the way down to the streams API would be to actually create a
/dev/null-like stream with a no-op writer function, and use that in
"svnadmin verify" instead.
>2) "svnadmin recover" can actually break a repository, if certain corruption
>patterns have been applied to the database files. This is nasty, but also,
>it means that unless recovery as just been run, svnadmin dump/verify are not
>assessing the long-term validity of the repository - problems may
>spontaneously develop when currently active logfiles are concluded.
>
>
I don't think we can do much about that. BDB can't protect us from
random data changes, so if you want robustness at this level, RAID 5 is
your friend.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 6 16:21:09 2004