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

Decompression of svndiff data failed

From: Michael Ditum <mike_at_mikeditum.co.uk>
Date: Thu, 29 Aug 2019 19:49:34 +0100


We've been running a subversion server since 2003, over the years we've
come across the svndiff decompression error numerous times, it's almost
always when we're committing binary files to the repository. Historically
we've always noticed it quite quickly and fixed the issue by deleting the
offending file and re-committing it. This solved the immediate problem
where other people could not checkout or update the repo but it's left the
offending revisions in our repo.

As we're running a ridiculously old subversion server (1.4.4) on a
ridiculously old operating system (Fedora 7) I've decided it's time to
migrate to a new server. I'm also looking at making read only mirrors
available in our other offices to save time checking out applications over
the WAN and to provide geographically separate backups. In order to do this
I've been using svnsync to replicate a copy of the repository to a
different server.

As I've come across the svndiff errors I've been using the fsfsverify.py to
fix them and so far it's worked and I've got to revision 24953 of 83080.
Unfortunately I have now got to a revision that fsfsverify.py has been
unable to fix, it keeps on detecting problems and fixing them but does this
with ever changing offsets and amount until it gets to the point where it
just constantly cycles between 2 different sets of offfsets and amounts.

The error fsfsverify originally comes out with is...

Error InvalidCompressedStream: Invalid compressed instr stream at offset
154848839 (Error -3 while decompressing: incorrect header check)

Unfortunately the binary file that got corrupted was a copy of an open
office install package which makes the revision 150MB and thus is rather
tricky to fix by hand.

Apart from using fsfsverify I also tried recreating the diff by creating a
Fedora 7 VM, running svnsync on it to copy the repo up to that point and
then manually committing the file and copying the revision over to the copy
of my original repo. Whilst this allows svnsync to get past that revision I
then started having lots of problems with incorrect byte offsets in later
revisions and once I (think I correctly) fixed started getting checksum
errors. Once I (again think I correctly) fixed those I then got another
error. At which point I decided I was disappearing down a rabbit hole and
gave up.

Does anyone have any ideas on how I can fix this revision? As I mentioned
before, the file gets deleted a couple of revisions later so I don't really
care about the contents of the revision but I'm currently stuck and can't
get any further in my svnsync.

Thanks in advance for your help!

Received on 2019-08-29 20:49:58 CEST

This is an archived mail posted to the Subversion Users mailing list.