On 04/01/2014 10:21 PM, Jeff King wrote: > On Tue, Apr 01, 2014 at 05:58:20PM +0200, Michael Haggerty wrote: > >> It's bad manners. Especially since, if unlink_or_warn() failed, the >> memory wasn't restored to its original contents. >> >> So make our own copy to work with. > > Sounds good... > >> if (!(flag & REF_ISPACKED) || flag & REF_ISSYMREF) { >> - /* loose */ >> - int err, i = strlen(lock->lk->filename) - 5; /* .lock */ >> - >> - lock->lk->filename[i] = 0; >> - err = unlink_or_warn(lock->lk->filename); >> - lock->lk->filename[i] = '.'; >> + /* >> + * loose. The loose file name is the same as the >> + * lockfile name, minus ".lock": >> + */ >> + char *loose_filename = xmemdupz(lock->lk->filename, >> + strlen(lock->lk->filename) - 5); >> + int err = unlink_or_warn(loose_filename); >> + free(loose_filename); > > Should we be using LOCK_SUFFIX_LEN from the previous commit here? LOCK_SUFFIX_LEN is not in scope to this file, and I think it should stay that way. But never fear; this figuring-out-filename-from-lockfile-name nonsense is gone by the end of the patch series. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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