Subject: Re: [PATCH v4 06/32] lockfile: unlock file if lockfile permissions cannot be adjusted

From: Michael Haggerty <[email-masked]>
Date: Fri, 12 Sep 2014 13:03:15 +0200

On 09/10/2014 12:39 AM, Junio C Hamano wrote:
> Michael Haggerty <[email-masked]> writes:
> 
>> If the call to adjust_shared_perm() fails, lock_file returns -1, which
>> to the caller looks like any other failure to lock the file.  So in
>> this case, roll back the lockfile before returning so that the lock
>> file is deleted immediately and the lockfile object is left in a
>> predictable state (namely, unlocked).  Previously, the lockfile was
>> retained until process cleanup in this situation.
> 
> ... which would mean that other processes can grab a lock on the
> same file a bit earlier. Is there any negative implication caused by
> that difference?  I do not think of any but I could be missing
> something.

I think the end effect would be the same as if another process had
grabbed the lock a nanosecond before this process tried to do so. So
assuming that callers handle that situation correctly, I don't think
this change can cause any problems.

Michael

-- 
Michael Haggerty
[email-masked]