Re: [PATCH] Correctly report corrupted objects
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 20, 2011, 21:17 UTC
- Message-ID
- <7voc7bqnpu.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <7vsjwnqoao.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 17 quoted lines
> Björn Steinbrink <B.Steinbrink@gmx.de> writes: > >> The errno check added in commit 3ba7a06 "A loose object is not corrupt >> if it cannot be read due to EMFILE" only checked for whether errno is >> not ENOENT and thus incorrectly treated "no error" as an error >> condition. >> >> Because of that, it never reached the code path that would report that >> the object is corrupted and instead caused funny errors like: >> >> fatal: failed to read object 333c4768ce595793fdab1ef3a036413e2a883853: Success >> >> So we have to extend the check to cover the case in which the object >> file was successfully read, but its contents are corrupted. > > Hmm, what is the exact code path that read_object() callchain fails to set > errno when it returns a NULL? It is unclear from the above description.
Ah, nevermind. I wasn't thinking. If for example unpack_sha1_header() says the type bits are garbled, it will return -1 without having any system calls failed up to that point (because the file itself was mmapped and read correctly) and the calling unpack_sha1_file() will return NULL.