Junio C Hamano <gitster@xxxxxxxxx> writes: > BjÃrn Steinbrink <B.Steinbrink@xxxxxx> 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. -- 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