Removing a lockfile once should be enough.
Signed-off-by: Sven Verdoolaege <skimo@xxxxxxxxxx>
---
...unless we're running on VMS.
Anyway, it's not clear to me why we can't remove lk from
lock_file_list (and then free it) after we unlink it
in unlock_ref.
skimo
lockfile.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 5ad2858..fb8f13b 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -31,16 +31,16 @@ static int lock_file(struct lock_file *lk, const char *path)
sprintf(lk->filename, "%s.lock", path);
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
+ if (!lock_file_list) {
+ signal(SIGINT, remove_lock_file_on_signal);
+ atexit(remove_lock_file);
+ }
lk->owner = getpid();
if (!lk->on_list) {
lk->next = lock_file_list;
lock_file_list = lk;
lk->on_list = 1;
}
- if (lock_file_list) {
- signal(SIGINT, remove_lock_file_on_signal);
- atexit(remove_lock_file);
- }
if (adjust_shared_perm(lk->filename))
return error("cannot fix permission bits on %s",
lk->filename);
--
1.5.3.rc1.10.gae1ae
-
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
