{"thread":{"id":"5382","subject":"Re: Problem with pack","startedAt":"2006-08-25T12:31:24Z","lastAt":"2006-08-26T18:20:18Z","messageCount":2,"participants":["Sergio Callegari","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25888","messageId":"44EEED9C.1010000@arces.unibo.it","threadId":"5382","inReplyTo":null,"subject":"Re: Problem with pack","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2006-08-25T12:31:24Z","receivedAt":"2006-08-25T12:31:24Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":">\n> Andreas Ericsson <ae@op5.se> writes:\n>\n> >> Btw, even without that, if I understand correctly, git packs are\n> >> collections of compressed objects, each of which has its own header\n> >> stating how long is the compressed object itself. In my case, the\n> >> error is in inflating one object (git unpack-objects says inflate\n> >> returns -3)... so shouldn't there be a way to try to skip to the\n> >> next object even in this case?\n> >\n> > It should be possible, assuming the pack index is still intact. The\n> > pack index is where the headers are stored, afaik.\n>\n> The problem Sergio seems to be having is because somehow he does\n> not have a base object that another object that is in the pack\n> depends on, because the latter object is stored in deltified\n> form.\n>\n> This should never happen unless .pack itself is corrupted\n> (git-pack-objects, unless explicitly told to do so with --thin\n> flag to git-rev-list upstream, would not make a delta against\n> objects not in the same pack).\n>\n> When a delta is written to the pack file, unless its base object\n> has already written out, git-pack-objects writes out the base\n> object immediately after that deltified object.  So one\n> possibility is that the pack was truncated soon after the delta\n> that is having trouble with finding its base object.  In such a\n> case, the proposed recovery measure of skipping the corruption\n> and keep going would not buy you that much.  On the other hand,\n> if the corruption is in the middle (e.g. a single disk block was\n> wiped out), having .idx file might help you resync.\n>\n> Does the pack pass git-verify-pack test, I wonder?\nIf I try to verify the pack I get:\n\ngit verify-pack -v pack-ebcdfbbda07e5a3e4136aa1f499990b35685bab4.idx\nfatal: failed to read delta-pack base object \n2849bd2bd8a76bbca37df2a4c8e8b990811d01a7\n\n\nthe package length seems reasonable, however... (no evident sign of \ntruncation, but I haven't looked inside the index to check the exact \npositions of objects)...\nand git unpack-object dies with error code -3 in inflate...\nIf I am not wrong (but I might easily be so) this should not be relative \nto truncation...\n\nSergio\n"},{"id":"25948","messageId":"Pine.LNX.4.64.0608261115570.11811@g5.osdl.org","threadId":"5382","inReplyTo":"44EEED9C.1010000@arces.unibo.it","subject":"Re: Problem with pack","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-08-26T18:20:18Z","receivedAt":"2006-08-26T18:20:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 25 Aug 2006, Sergio Callegari wrote:\n>\n> If I try to verify the pack I get:\n> \n> git verify-pack -v pack-ebcdfbbda07e5a3e4136aa1f499990b35685bab4.idx\n> fatal: failed to read delta-pack base object 2849bd2bd8a76bbca37df2a4c8e8b990811d01a7\n> \n> the package length seems reasonable, however... (no evident sign of\n> truncation, but I haven't looked inside the index to check the exact positions\n> of objects)...\n\nCan you make the corrupt pack-file and index available publically (or \nperhaps at least to a few git people?)\n\nThe fact that verify-pack is happy with the SHA1 checksum is interesting, \nbecause it means that the pack-file at least didn't get corrupted on-disk \n(or through the sync operation). Iow, it must have gotten corrupted at \nwrite-out itself somehow, and it would be interesting to see what the \npack-file looks like.\n\n> and git unpack-object dies with error code -3 in inflate...\n\nThat's Z_DATA_ERROR, which is what you get if the input to inflate is bad.\n\n\t\tLinus\n"}]}