Better error messages for corrupt databases
commit9130ac1e1966adb9922e64f645730d0d45383495
authorLinus Torvalds <torvalds@osdl.org>
Thu, 11 Jan 2007 22:09:31 +0000 (11 14:09 -0800)
committerJunio C Hamano <junkio@cox.net>
Thu, 11 Jan 2007 22:44:17 +0000 (11 14:44 -0800)
treefa442a758f86f26e26621a93ad94f2fa84b05982
parent93c1e07947e83f13fa8f1c89cb4897b5c71459ff
Better error messages for corrupt databases

This fixes another problem that Andy's case showed: git-fsck-objects
reports nonsensical results for corrupt objects.

There were actually two independent and confusing problems:

 - when we had a zero-sized file and used map_sha1_file, mmap() would
   return EINVAL, and git-fsck-objects would report that as an insane and
   confusing error. I don't know when this was introduced, it might have
   been there forever.

 - when "parse_object()" returned NULL, fsck would say "object not found",
   which can be very confusing, since obviously the object might "exist",
   it's just unparseable because it's totally corrupt.

So this just makes "xmmap()" return NULL for a zero-sized object (which is
a valid thing pointer, exactly the same way "malloc()" can return NULL for
a zero-sized allocation). That fixes the first problem (but we could have
fixed it in the caller too - I don't personally much care whichever way it
goes, but maybe somebody should check that the NO_MMAP case does
something sane in this case too?).

And the second problem is solved by just making the error message slightly
clearer - the failure to parse an object may be because it's missing or
corrupt, not necessarily because it's not "found".

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fsck-objects.c
git-compat-util.h