From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Sun, 14 Sep 2014 06:38:01 GMT
Subject: Re: [PATCH v4 11/32] delete_ref_loose(): don't muck around in the lock_file's filename
Message-ID: <541537C9.1080304@alum.mit.edu>
In-Reply-To: <5415353E.8060907@alum.mit.edu>

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.

I will clarify the log message.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu