Re: "failed to read delta base object at..."

From: Nicolas Pitre <nico@cam.org>
Date: Aug 27, 2008, 20:46 UTC
Message-ID: <alpine.LFD.1.10.0808271627540.1624@xanadu.home>
In-Reply-To: <alpine.LFD.1.10.0808271222250.3363@nehalem.linux-foundation.org>

On Wed, 27 Aug 2008, Linus Torvalds wrote:

Show 8 quoted lines

> On Wed, 27 Aug 2008, Nicolas Pitre wrote:
> 
> > However, in the pack-objects case, it is almost impossible to have such 
> > a corruption since the data is SHA1 summed immediately before being 
> > written out.
> 
> Yes. Anything that uses the "sha1write()" model (which includes the 
> regular pack-file _and_ the index) should generally be pretty safe.

What that means is that if git was the cause of the corruption itself then the pack would still match its checksum (verify-pâck would still fail nevertheless).

Show 10 quoted lines

> However, we do have this odd case of fixing up the pack after-the-fact 
> when we receive it from somebody else (because we get a thin pack and 
> don't know how many objects the final result will have). And that case 
> seems to be not as safe, because it
> 
>  - re-reads the file to recompute the SHA1
> 
>    This is understandable, and it's fairly ok, but it does mean that there 
>    is a bigger chance of the SHA1 matching if something has corrupted the 
>    file in the meantime!

I think that can be fixed. When reading the file back, it is possible to compute 2 sha1s: one to compare with the recieved one using original pack header, and the second which would be the final one. FRom a certain offset, new objects were added, so that first sha1 is validated against the received one and reset, and at the end, it should correspond to the sha1 of added objects that we should compute when writing them.

Nicolas