Re: Problem with pack

Andreas Ericsson [off-list ref] writes:

quoted

quoted

Btw, even without that, if I understand correctly, git packs are
collections of compressed objects, each of which has its own header
stating how long is the compressed object itself. In my case, the
error is in inflating one object (git unpack-objects says inflate
returns -3)... so shouldn't there be a way to try to skip to the
next object even in this case?

It should be possible, assuming the pack index is still intact. The
pack index is where the headers are stored, afaik.

The problem Sergio seems to be having is because somehow he does
not have a base object that another object that is in the pack
depends on, because the latter object is stored in deltified
form.

This should never happen unless .pack itself is corrupted
(git-pack-objects, unless explicitly told to do so with --thin
flag to git-rev-list upstream, would not make a delta against
objects not in the same pack).

When a delta is written to the pack file, unless its base object
has already written out, git-pack-objects writes out the base
object immediately after that deltified object.  So one
possibility is that the pack was truncated soon after the delta
that is having trouble with finding its base object.  In such a
case, the proposed recovery measure of skipping the corruption
and keep going would not buy you that much.  On the other hand,
if the corruption is in the middle (e.g. a single disk block was
wiped out), having .idx file might help you resync.

Does the pack pass git-verify-pack test, I wonder?

If I try to verify the pack I get:

git verify-pack -v pack-ebcdfbbda07e5a3e4136aa1f499990b35685bab4.idx
fatal: failed to read delta-pack base object 
2849bd2bd8a76bbca37df2a4c8e8b990811d01a7


the package length seems reasonable, however... (no evident sign of 
truncation, but I haven't looked inside the index to check the exact 
positions of objects)...
and git unpack-object dies with error code -3 in inflate...
If I am not wrong (but I might easily be so) this should not be relative 
to truncation...

Sergio

On Fri, 25 Aug 2006, Sergio Callegari wrote:

If I try to verify the pack I get:

git verify-pack -v pack-ebcdfbbda07e5a3e4136aa1f499990b35685bab4.idx
fatal: failed to read delta-pack base object 2849bd2bd8a76bbca37df2a4c8e8b990811d01a7

the package length seems reasonable, however... (no evident sign of
truncation, but I haven't looked inside the index to check the exact positions
of objects)...

Can you make the corrupt pack-file and index available publically (or 
perhaps at least to a few git people?)

The fact that verify-pack is happy with the SHA1 checksum is interesting, 
because it means that the pack-file at least didn't get corrupted on-disk 
(or through the sync operation). Iow, it must have gotten corrupted at 
write-out itself somehow, and it would be interesting to see what the 
pack-file looks like.

and git unpack-object dies with error code -3 in inflate...

That's Z_DATA_ERROR, which is what you get if the input to inflate is bad.

		Linus