From: Johannes Sixt <j6t@kdbg.org>
Date: Sun, 14 Sep 2014 14:49:11 GMT
Subject: Re: [PATCH v4 11/32] delete_ref_loose(): don't muck around in the lock_file's filename
Message-ID: <5415AAE7.3060806@kdbg.org>
In-Reply-To: <541537C9.1080304@alum.mit.edu>

Am 14.09.2014 um 08:38 schrieb Michael Haggerty:
> On 09/14/2014 08:27 AM, Michael Haggerty wrote:
>> On 09/13/2014 09:41 AM, Johannes Sixt wrote:
>>> Am 06.09.2014 um 09:50 schrieb Michael Haggerty:
>>>> It's bad manners.  Especially since, if unlink_or_warn() failed, the
>>>> memory wasn't restored to its original contents.
>>>
>>> I do not see how the old code did not restore the file name. Except for
>>> this nit, the patch looks good.
>>
>> Hmmmm, you're quite right. I thought I had found some circumstance in
>> which unlink_or_warn() could fail to allocate memory and die() or
>> something. But I can't find anything like that now.
>>
>> I will remove that sentence from the commit message.
> 
> I half withdraw my withdrawal. It's true that the failure of
> unlink_or_warn() wouldn't cause a problem. But a signal could arrive
> while unlink_or_warn() is executing, in which case the signal handler
> would see the wrong filename and try to delete the loose reference file,
> leaving the lockfile behind.

Good catch! This makes the patch much more important than just to
establish good manners.

-- Hannes