Am 11/18/2010 15:19, schrieb Erik Faye-Lund: > What happens, is that read_object returns NULL, but errno is 0. > Further, it looks to me like read_object can only return NULL through > the unpack_sha1_file (problem with the compressed data) or > read_packed_sha1 (find_pack_entry() failure) code-paths. > > errno is set to ENOENT by open_sha1_file (through map_sha1_file) > before any possible error-points. I guess this makes the "errno = 0" > redundant, but I think it improves readability of the code. I'm > guessing that errno gets overwritten by some other call, losing the > ENOENT. Perhaps some unintended side-effect of one of the > compat/mingw.[ch]-wrappers? The problem is in opendir() called via prepare_packed_git_one() via prepare_packed_git(). It resets errno to 0 on success. You can test this easily by inserting test_done after the 3rd test of t5530 and run it with --debug; in the trash-directory you can run ../../git-pack-objects --revs --all --stdout >/dev/null </dev/null and observe the different failure modes on Windows and Linux. This makes me question whether the approach of Junio's fix is sane. It depends on errno being set *way* before it is checked and after *a*lot* of potentially failing system and library calls have been called. Which function is it that is expected to fail with ENOENT? git_open_noatime()? -- Hannes -- 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