Re: [PATCH 05/16] fsmonitor--daemon: refactor cookie handling for readability

From: Derrick Stolee <derrickstolee@github.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH 05/16] fsmonitor--daemon: refactor cookie handling for readability
Date: Mon, 14 Mar 2022 10:49:18 -0400	[thread overview]
Message-ID: <7ddeffc4-3442-b4a1-e6f4-e68b3aa3f5ec@github.com> (raw)
In-Reply-To: <220314.86bky9ezdw.gmgdl@evledraar.gmail.com>

On 3/14/2022 4:00 AM, Ævar Arnfjörð Bjarmason wrote:
> 
> On Fri, Mar 11 2022, Jeff Hostetler via GitGitGadget wrote:

>> +	/*
>> +	 * Technically, close() and unlink() can fail, but we don't
>> +	 * care here.  We only created the file to trigger a watch
>> +	 * event from the FS to know that when we're up to date.
>> +	 */
>> +	close(fd);
> 
> It still seems odd to explicitly want to ignore close() return values.
> 
> I realize that we do in (too many) existing places, but why wouldn't we
> want to e.g. catch an I/O error here early?

What exactly do you propose we do here if there is an I/O error
during close()?

Thanks,
-Stolee