Re: [PATCH 05/22] lockfile: unlock file if lockfile permissions cannot be adjusted
- From
Jeff King <peff@peff.net>
- Date
- Apr 1, 2014, 20:05 UTC
- Message-ID
- <20140401200559.GA22174@sigill.intra.peff.net>
- In-Reply-To
- <20140401200242.GD21715@sigill.intra.peff.net>
On Tue, Apr 01, 2014 at 04:02:42PM -0400, Jeff King wrote:
Show 15 quoted lines
> 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).
...and I should have read the final sentence in your message more carefully. Even if we did trigger it, the problem would only last until the program exits anyway.
I agree that this is a nice cleanup, though; a caller that wants to retry the lock before exiting would be much less surprised. And the same logic applies to 06/22.
-Peff