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

RE: "Decompression of svndiff data failed"

From: Chris Watson <cwatson_at_ptc.com>
Date: Mon, 30 Mar 2009 04:39:32 -0400

Is it the identical error? Or a minor variant? - e.g. is the offset
exactly the same?


I find that I need to run fsfsverify multiple times to fix each error.
It doesn't fix all the errors but only the first one it finds.


If it is the same error then you are pretty screwed. The only way that
I've ever found forward is to use svnadmin dump/load to recreate a
repository with everything up to the break, then do an svn co of the
damaged revision and pull out everything up to the fault, and then use
svn cat to pull out everything after the fault that you can. Then you
need to get new copies of the damaged file and recreate the revision -
you can then reapply the newer revisions on top with svnadmin dump/load




From: void pointer [mailto:rcdailey_at_gmail.com]
Sent: 28 March 2009 20:04
To: Christian Unger
Cc: users_at_subversion.tigris.org
Subject: Re: "Decompression of svndiff data failed"



On Fri, Mar 27, 2009 at 5:16 PM, Christian Unger
<christian.unger_at_me.com> wrote:

try this:



Thanks Christian.


I tried doing as you stated and I get the following when I run
fsfsverify without the -f option:


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

Try running with -f to fix the revision


When I run it with -f, it says it fixed it and to run fsfsverify without
the -f option to double check. When I run without -f the second time, I
get the very same error again as above.


Am I completely screwed?


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-30 10:40:53 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.