# Re: Problem with pack

2 messages from 2006-08-25 to 2006-08-26. Participants: Sergio Callegari, Linus Torvalds.
Thread: https://gitlist.dev/t/5382

## Sergio Callegari, 2006-08-25 12:31

Subject: Re: Problem with pack
Message-ID: <44EEED9C.1010000@arces.unibo.it>
URL: https://gitlist.dev/e/44EEED9C.1010000%40arces.unibo.it

```
>
> Andreas Ericsson <ae@op5.se> writes:
>
> >> 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

```

## Linus Torvalds, 2006-08-26 18:20

Subject: Re: Problem with pack
Message-ID: <Pine.LNX.4.64.0608261115570.11811@g5.osdl.org>
URL: https://gitlist.dev/e/Pine.LNX.4.64.0608261115570.11811%40g5.osdl.org
In-Reply-To: <44EEED9C.1010000@arces.unibo.it>

```


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

```