Re: [PATCH v4 19/32] commit_lock_file(): rollback lock file on failure to rename

From: Jeff King <peff@peff.net>
Date: Sep 10, 2014, 07:55 UTC
Message-ID: <20140910075519.GA16413@peff.net>
In-Reply-To: <1409989846-22401-20-git-send-email-mhagger@alum.mit.edu>

On Sat, Sep 06, 2014 at 09:50:33AM +0200, Michael Haggerty wrote:

> If rename() fails, call rollback_lock_file() to delete the lock file
> (in case it is still present) and reset the filename field to the
> empty string so that the lockfile object is left in a valid state.

Unlike the previous patch, in this case the contents of the lockfile _are_ defined. So in theory a caller could somehow retry.

I don't see any callers that want to do that, though (and besides, they would not know if the error came from the close or the rename), so I think we can consider that an uninteresting case until somebody creates such a caller (at which point they can take responsibility for extending the API).

BTW, while grepping for commit_lock_file calls, I notice we often commit the shallow file without checking the return code. I'm not sure what we should do in each case, but I imagine that calling die() is probably better than continuing as if it succeeded. +cc Duy

-Peff