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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2014, 22:39 UTC
Message-ID: <xmqqr3zkifl5.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1409989846-22401-7-git-send-email-mhagger@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 6 quoted lines

> 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.

Show 18 quoted lines

>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  lockfile.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/lockfile.c b/lockfile.c
> index b1c4ba0..d4f165d 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -153,6 +153,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
>  			int save_errno = errno;
>  			error("cannot fix permission bits on %s",
>  			      lk->filename);
> +			rollback_lock_file(lk);
>  			errno = save_errno;
>  			return -1;
>  		}