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