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

[Junio C Hamano <gitster@pobox.com>]

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.

>
> 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;
>  		}