Michael Haggerty <mhag...@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 <mhag...@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;
> }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
