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