summaryrefslogtreecommitdiff
path: root/Documentation/technical
diff options
context:
space:
mode:
authorLibravatar Michael Haggerty <mhagger@alum.mit.edu>2014-10-01 12:28:22 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-10-01 13:45:13 -0700
commit8e86c155d2962f5dff83c9d0d88b836bf040c1fa (patch)
tree6b9eef5ab880a3249cdb4cab59a19d19ee3049fc /Documentation/technical
parentcommit_lock_file(): die() if called for unlocked lockfile object (diff)
downloadtgif-8e86c155d2962f5dff83c9d0d88b836bf040c1fa.tar.xz
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>
Diffstat (limited to 'Documentation/technical')
-rw-r--r--Documentation/technical/api-lockfile.txt7
1 files changed, 4 insertions, 3 deletions
diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt
index 6538610759..d3bf940ad4 100644
--- a/Documentation/technical/api-lockfile.txt
+++ b/Documentation/technical/api-lockfile.txt
@@ -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::