Re: [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list

2014-04-07 Thread Jeff King
On Sun, Apr 06, 2014 at 11:54:59PM +0200, Michael Haggerty wrote: I didn't reproduce it experimentally, though. We should be able to just lk-owner = 0; before the initial strcpy to fix it, I would think. I think that using the owner field to avoid this problem is a bit

Re: [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list

2014-04-06 Thread Michael Haggerty
On 04/01/2014 10:16 PM, Jeff King wrote: On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote: diff --git a/lockfile.c b/lockfile.c index e679e4c..c989f6c 100644 --- a/lockfile.c +++ b/lockfile.c @@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char

Re: [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list

2014-04-02 Thread Junio C Hamano
Jeff King p...@peff.net writes: So for a moment, lk-filename contains the name of the valuable file we are locking. If we get a signal at that moment, do we accidentally delete it in remove_lock_file? I think the answer is no, because we check lk-owner before deleting, which will not match

[PATCH 07/22] lock_file(): always add lock_file object to lock_file_list

2014-04-01 Thread Michael Haggerty
It used to be that if locking failed, lock_file() usually did not register the lock_file object in lock_file_list but sometimes it did. This confusion was compounded if lock_file() was called via hold_lock_file_for_append(), which has its own failure modes. The ambiguity didn't have any ill

Re: [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list

2014-04-01 Thread Jeff King
On Tue, Apr 01, 2014 at 05:58:15PM +0200, Michael Haggerty wrote: diff --git a/lockfile.c b/lockfile.c index e679e4c..c989f6c 100644 --- a/lockfile.c +++ b/lockfile.c @@ -130,6 +130,22 @@ static int lock_file(struct lock_file *lk, const char *path, int flags) */ static const