From: Junio C Hamano Date: Thu, 20 Jan 2011 21:17:33 GMT Subject: Re: [PATCH] Correctly report corrupted objects Message-ID: <7voc7bqnpu.fsf@alter.siamese.dyndns.org> In-Reply-To: <7vsjwnqoao.fsf@alter.siamese.dyndns.org> Junio C Hamano writes: > Björn Steinbrink 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.