Removing a lockfile once should be enough.

Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
...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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html