Re: [PATCH v5 07/35] hold_lock_file_for_append(): release lock on errors
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Sep 16, 2014, 20:48 UTC
- Message-ID
- <20140916204853.GH29050@google.com>
- In-Reply-To
- <1410896036-12750-8-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty wrote:
Show 9 quoted lines
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -219,13 +219,13 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
> if (errno != ENOENT) {
> if (flags & LOCK_DIE_ON_ERROR)
> die("cannot open '%s' for copying", path);
> - close(fd);
> + rollback_lock_file(lk);
> return error("cannot open '%s' for copying", path);Makes sense.
Now that I'm here, I wonder a little at the error convention. If the caller doesn't pass LOCK_DIE_ON_ERROR, are they supposed to be able to use unable_to_lock_message? What errno would they pass in the err parameter? Would callers want handle failure to acquire a lock differently from other errors (e.g., by sleeping and trying again), and if not, what is the optionally-die behavior in hold_lock_file about?
In any case, Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>