From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Fri, 12 Sep 2014 11:03:15 GMT
Subject: Re: [PATCH v4 06/32] lockfile: unlock file if lockfile permissions cannot be adjusted
Message-ID: <5412D2F3.50404@alum.mit.edu>
In-Reply-To: <xmqqr3zkifl5.fsf@gitster.dls.corp.google.com>

On 09/10/2014 12:39 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> 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
mhagger@alum.mit.edu