git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Michael Haggerty <mhagger@alum.mit.edu>
Subject: [PATCH 05/22] lockfile: unlock file if lockfile permissions cannot be adjusted
Date: Tue,  1 Apr 2014 17:58:13 +0200	[thread overview]
Message-ID: <1396367910-7299-6-git-send-email-mhagger@alum.mit.edu> (raw)
In-Reply-To: <1396367910-7299-1-git-send-email-mhagger@alum.mit.edu>

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 <mhagger@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

  parent reply	other threads:[~2014-04-01 16:00 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 15:58 [PATCH 00/22] Lockfile refactoring and pre-activation Michael Haggerty
2014-04-01 15:58 ` [PATCH 01/22] t3204: test deleting references when lock files already exist Michael Haggerty
2014-04-01 19:53   ` Jeff King
2014-04-02 10:28     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 02/22] try_merge_strategy(): remove redundant lock_file allocation Michael Haggerty
2014-04-01 19:56   ` Jeff King
2014-04-02 10:53     ` Michael Haggerty
2014-04-02 16:53     ` Junio C Hamano
2014-04-03 12:43       ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 03/22] rollback_lock_file(): do not clear filename redundantly Michael Haggerty
2014-04-01 15:58 ` [PATCH 04/22] rollback_lock_file(): set fd to -1 Michael Haggerty
2014-04-01 19:59   ` Jeff King
2014-04-02 16:58     ` Junio C Hamano
2014-04-06 21:45       ` Michael Haggerty
2014-04-07 16:37         ` Junio C Hamano
2014-04-01 15:58 ` Michael Haggerty [this message]
2014-04-01 20:02   ` [PATCH 05/22] lockfile: unlock file if lockfile permissions cannot be adjusted Jeff King
2014-04-01 20:05     ` Jeff King
2014-04-02  6:47   ` Torsten Bögershausen
2014-04-06 22:02     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 06/22] hold_lock_file_for_append(): release lock on errors Michael Haggerty
2014-04-01 15:58 ` [PATCH 07/22] lock_file(): always add lock_file object to lock_file_list Michael Haggerty
2014-04-01 20:16   ` Jeff King
2014-04-02 17:01     ` Junio C Hamano
2014-04-06 21:54     ` Michael Haggerty
2014-04-07  9:36       ` Jeff King
2014-04-01 15:58 ` [PATCH 08/22] struct lock_file: replace on_list field with flags field Michael Haggerty
2014-04-01 15:58 ` [PATCH 09/22] api-lockfile: expand the documentation Michael Haggerty
2014-04-01 20:19   ` Jeff King
2014-04-02 11:36     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 10/22] lockfile.c: document the various states of lock_file objects Michael Haggerty
2014-04-01 15:58 ` [PATCH 11/22] lockfile: define a constant LOCK_SUFFIX_LEN Michael Haggerty
2014-04-02 17:27   ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 12/22] delete_ref_loose(): don't muck around in the lock_file's filename Michael Haggerty
2014-04-01 20:21   ` Jeff King
2014-04-02 11:50     ` Michael Haggerty
2014-04-02  6:52   ` Torsten Bögershausen
2014-04-02  6:55     ` Jeff King
2014-04-01 15:58 ` [PATCH 13/22] config: change write_error() to take a (struct lock_file *) argument Michael Haggerty
2014-04-02  6:58   ` Torsten Bögershausen
2014-04-06 22:04     ` Michael Haggerty
2014-04-02 17:29   ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 14/22] lockfile: use strbufs when handling (most) paths Michael Haggerty
2014-04-01 20:28   ` Jeff King
2014-04-02 17:16   ` Junio C Hamano
2014-04-01 15:58 ` [PATCH 15/22] resolve_symlink(): use a strbuf internally Michael Haggerty
2014-04-01 15:58 ` [PATCH 16/22] commit_lock_file(): don't work with a fixed-length buffer Michael Haggerty
2014-04-01 15:58 ` [PATCH 17/22] lock_file(): exit early if lockfile cannot be opened Michael Haggerty
2014-04-01 15:58 ` [PATCH 18/22] lockfile: also keep track of the filename of the file being locked Michael Haggerty
2014-04-02 17:19   ` Junio C Hamano
2014-04-06 22:05     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 19/22] struct lock_file: rename lock_filename field to staging_filename Michael Haggerty
2014-04-01 15:58 ` [PATCH 20/22] remove_lock_file(): call rollback_lock_file() Michael Haggerty
2014-04-01 15:58 ` [PATCH 21/22] lockfile: extract a function reset_lock_file() Michael Haggerty
2014-04-02  7:06   ` Eric Sunshine
2014-04-02 13:37     ` Michael Haggerty
2014-04-01 15:58 ` [PATCH 22/22] lockfile: allow new file contents to be written while retaining lock Michael Haggerty
2014-04-01 20:39   ` Jeff King
2014-04-02  7:20   ` Eric Sunshine
2014-04-02 17:26   ` Junio C Hamano
2014-04-01 20:44 ` [PATCH 00/22] Lockfile refactoring and pre-activation Jeff King
2014-04-03 11:42   ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1396367910-7299-6-git-send-email-mhagger@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).