From: Jeff King <peff@peff.net>
Date: Tue, 01 Apr 2014 20:02:42 GMT
Subject: Re: [PATCH 05/22] lockfile: unlock file if lockfile permissions cannot be adjusted
Message-ID: <20140401200242.GD21715@sigill.intra.peff.net>
In-Reply-To: <1396367910-7299-6-git-send-email-mhagger@alum.mit.edu>

On Tue, Apr 01, 2014 at 05:58:13PM +0200, Michael Haggerty wrote:

> 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 that (namely, unlocked).  Previously, the lockfile
> was retained until process cleanup in this situation.

Another nice find. I wondered if we could test this, but I think it
would be hard to trigger. The obvious reason for adjust_shared_perm to
fail is that you do not have permissions on the file, but by definition
you just created it. So I doubt this ever comes up in practice short of
weird races (somebody dropping the "x" bit from an intermediate
directory between the open() and chmod() or something).

-Peff