If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file.  So in
this case, roll back the lockfile before returning so that the lock
file is deleted immediately and the lockfile object is left in a
predictable state that (namely, unlocked).  Previously, the lockfile
was retained until process cleanup in this situation.

Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
 lockfile.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lockfile.c b/lockfile.c
index c1af65b..1928e5e 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -148,9 +148,11 @@ static int lock_file(struct lock_file *lk, const char 
*path, int flags)
                        lock_file_list = lk;
                        lk->on_list = 1;
                }
-               if (adjust_shared_perm(lk->filename))
-                       return error("cannot fix permission bits on %s",
-                                    lk->filename);
+               if (adjust_shared_perm(lk->filename)) {
+                       error("cannot fix permission bits on %s", lk->filename);
+                       rollback_lock_file(lk);
+                       return -1;
+               }
        }
        else
                lk->filename[0] = 0;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to