close_lock_file(): if close fails, roll back

If closing an open lockfile fails, then we cannot be sure of the
contents of the lockfile, so there is nothing sensible to do but
delete it. This change also insures that the lock_file object is left
in a defined state in this error path (namely, unlocked).

The only caller that is ultimately affected by this change is
try_merge_strategy() -> write_locked_index(), which can call
close_lock_file() via various execution paths. This caller uses a
static lock_file object which previously could have been reused after
a failed close_lock_file() even though it was still in locked state.
This change causes the lock_file object to be unlocked on failure,
thus fixing this error-handling path.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Michael Haggerty
2014-10-01 12:28:22 +02:00
committed by Junio C Hamano
parent 8a1c7533e2
commit 8e86c155d2
2 changed files with 22 additions and 13 deletions

View File

@ -162,9 +162,10 @@ close_lock_file::
Take a pointer to the `struct lock_file` initialized with an
earlier call to `hold_lock_file_for_update` or
`hold_lock_file_for_append`, and close the file descriptor.
Return 0 upon success or a negative value on failure to
close(2). Usually `commit_lock_file` or `rollback_lock_file`
should be called after `close_lock_file`.
Return 0 upon success. On failure to `close(2)`, return a
negative value and rollback the lock file. Usually
`commit_lock_file` or `rollback_lock_file` should eventually
be called if `close_lock_file` succeeds.
reopen_lock_file::