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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
