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

Re: Some parts of repository corrupted - how to recover?

From: <kfogel_at_collab.net>
Date: 2003-05-13 16:59:33 CEST

Edmund Horner <edmund@chrysophylax.cjb.net> writes:
> Dumping my repository fails on rev 81:
>
> $ svnadmin dump e:\svn -r 81 > svn-dump-81
> svn: Filesystem is corrupt
> svn: txn_body_read_rep: checksum mismatch on rep "2bc":
> expected: 55b7db82c802ce6418b983e6ac27516c
> actual: f6cfdc3a53e178d783f614a820a2bf33

Do you know what the contents of that file should be? (And do those
contents match either of the checksums?)

If you can't get the contents, then make a copy of your repository,
find the checksum in the db/representations representations table and
edit it from

   55b7db82c802ce6418b983e6ac27516c

to

   00000000000000000000000000000000

Then try again (using the copy, of course). The all-zeros checksum
always matches in Subversion.

> The last part of the partially dumped svn-dump-81 looks like:
>
> Node-path: compendium1/trunk/work/dump.pcx
> Node-kind: file
> Node-action: add
> Prop-content-length: 59
> Text-content-length: 275595
> Text-content-md5: 55b7db82c802ce6418b983e6ac27516c
> Content-length: 275654
>
> K 13
> svn:mime-type
> V 24
> application/octet-stream
> PROPS-END
> some binary data...
>
> Revisions 1-80 can be dumped. Revisions after 81 CANNOT be dumped.
>
> "svnadmin recover" just goes ahead and runs as if nothing's wrong.
>
> From experimentation, paths that don't contain this (or other)
> problem files can be checked out. There are some other problem files
> where the same problem occurs, in different revisions and paths.
>
> My guess is that the data for certain paths,
> e.g. compendium1/trunk/work/dump.pcx is screwed up. Or maybe it's
> just the checksums.
>
> Although I don't have a definitive list of problem paths, I'm prepared
> to lose those files (the example I gave above is easily
> replacable). How can I most easily recover those paths which aren't
> corrupted?
>
> Is this another use case for "svn obliterate" ?

Nah, it's a case for finding & fixing the cause of the problem :-).

> BTW, it's probably the unreliability of my machine that causes this (I
> seem to get more than my share of cosmic rays here ;-), so I don't
> want anyone to panic about bugs yet.

Oh, well, thanks, that's reassuring in a way... How can you work on a
machine that randomly changes bits, man? :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 17:43:04 2003

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.