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@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html