On Sat, 25 Aug 2007, Shawn O. Pearce wrote:
cate on #git noticed this failure in `git fsck --full` where the
call to verify_pack() first noticed that the packfile was corrupt
by finding that the packfile's SHA-1 did not match the raw data of
the file. After finding this fsck went ahead and tried to verify
every object within the packfile, even though the packfile was
already known to be bad. If we are going to shovel bad data at
the delta unpacking code, we better handle it correctly.
Hmm. We should actually make "unpack_entry()" return print an error and
return NULL for these cases, rather than die, I think.
Most of the callers seem to already check for NULL (not "load_tree()" in
fast-import.c), but for something like fsck, while "die()" is obviously
better than a SIGSEGV, we should probably continue and try to see what
else we find.
(Although, to be honest, it might not matter. If your pack-file is corrupt
enough for this to trigger, there's seldom anything interesting fsck will
tell, so in practical terms this probably isn't a big deal).
Linus