From: Johannes Sixt <j.sixt@viscovery.net>
Date: Thu, 18 Nov 2010 16:43:00 GMT
Subject: Re: [PATCH 2/2] A loose object is not corrupt if it cannot be read due to EMFILE
Message-ID: <4CE55794.7050201@viscovery.net>
In-Reply-To: <AANLkTi=L1Z6kxubMf3yPUfpY9ugd+Qan+yCxi3dp4oR4@mail.gmail.com>

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