Hello, I've an interesting case of repository corruption about which I've not been able to find any information.
I've version 1.5.6 using FSFS stored on ext3 (RHEL 5.4). The repository contains about 39k revisions. Revisions 0-36672 are fine and dump without any problems. Revisions 36673-8 fail to verify and give the following error: svnadmin: Revision file lacks trailing newline The same revisions fail to dump and give the following error: svnadmin: Can't read length line in file 'repo/db/revs/36/3667x The failing revisions are on disk with varying, seemingly normal-looking lengths: -rw-r--r-- 1 root apache 39104 May 13 17:50 repo/db/revs/36/36673 -rw-r--r-- 1 root apache 28168 May 13 17:50 repo/db/revs/36/36674 -rw-r--r-- 1 root apache 27831 May 13 17:50 repo/db/revs/36/36675 -rw-r--r-- 1 root apache 18112 May 13 17:50 repo/db/revs/36/36676 -rw-r--r-- 1 root apache 8983 May 13 17:50 repo/db/revs/36/36677 -rw-r--r-- 1 root apache 28577 May 13 17:50 repo/db/revs/36/36678 When I inspect these files with a hex editor I find that they're full of only zeros. That seems to explain why svn is choking on them. I suspect that this occurred during an episode a couple of months ago when the server's storage was yanked out from under it unexpectedly. fsfsverify.py also chokes on these revisions when trying to seek within them. 36679-HEAD seem to be fine as users have been committing and checking out since then. A couple of days ago, however, local checkouts started failing with the following error (the rev file listed is going to be one of the failing revisions): svn: Can't read length line in file '/data3/tmp/repo/db/revs/36/3667x' It looks like certain checkouts hit a file which prompts svn to try and read those revisions and subsequently fail. As a result we have a project which is unusable at the moment. Verification and dumping from 36679-HEAD will proceed until it hits a reference back to one of the borked revisions and them terminate. I can't even dump both halves of the repo and reimport omitting 36673-36678. I'm kind of stuck as to how to fix this. Can I try to insert mocked-up empty revisions in place of the zeroed ones so that svn can proceed with dumping the more recent half of the repository or is there a better way to do this? Thanks in advance for any help anyone may be able to offer. Christian
signature.asc
Description: OpenPGP digital signature