Re: [PATCH v4 11/32] delete_ref_loose(): don't muck around in the lock_file's filename
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Sep 14, 2014, 06:38 UTC
- 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:
Show 13 quoted lines
> 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