threads / patch / 44796

v3, 23 partsfiles_rename_ref(): tidy up whitespace

Subject: [PATCH v3 01/23] files_rename_ref(): tidy up whitespace

## tl;dr

55 messages between Dec 31, 2016 and Jan 2, 2017. Diffs are folded; open one to read it.

replies: 54people: 5as markdown or json

Michael Haggerty· Dec 31, 2016, 03:12 UTC · lore

[PATCH v3 00/23] Delete directories left empty after ref deletion

This is a re-roll of an old patch series. v1 [1] got some feedback, which I think was all addressed in v2 [2]. But it seems that v2 fell on the floor, and I didn't bother following up because it was in the same area of code that was undergoing heavy changes due to the pluggable reference backend work. Sorry for the long delay before getting back to it.

It turns out that this patch series is still relevant and didn't even need all that must adjustment. While rebasing onto the current `master`, I tidied up a bit, tightened up some code, and improved some commit messages. But the spirit of the patch series and most of its code are unchanged.

This patch series is also available from my GitHub account [3] as branch delete-empty-refs-dirs.

Brief summary (see v1 [1] for more details):

Previously, we were pretty sloppy about leaving empty directories behind (under both $GIT_DIR/refs and $GIT_DIR/logs) when deleting references. Such directories could accumulate essentially forever. It's true that `pack-refs` deletes directories that it empties, but if a directory is *already* empty, then `pack-refs` doesn't remove it. It is also true that if an empty directory gets in the way of the creation of a *new* reference, then it is deleted. But otherwise there is no systematic cleanup of empty directories.

A reason for the old behavior was that the code paths *creating* new files in these hierarchies were not always robust against a race with another process that was cleaning up empty directories. So most of this patch series is dedicated to hardening up the creation code paths (via a new function, `raceproof_create_file()`). The last several patches teach `files_transaction_commit()` to delete empty directories when deleting references and reflogs.

Michael

[1] http://public-inbox.org/git/cover.1455626201.git.mhagger@alum.mit.edu/T/#u [2] http://public-inbox.org/git/cover.1456405698.git.mhagger@alum.mit.edu/T/#u [3] http://github.com/mhagger/git

Michael Haggerty (23):
  files_rename_ref(): tidy up whitespace
  t5505: use "for-each-ref" to test for the non-existence of references
  safe_create_leading_directories_const(): preserve errno
  safe_create_leading_directories(): set errno on SCLD_EXISTS
  raceproof_create_file(): new function
  lock_ref_sha1_basic(): inline constant
  lock_ref_sha1_basic(): use raceproof_create_file()
  rename_tmp_log(): use raceproof_create_file()
  rename_tmp_log(): improve error reporting
  log_ref_write(): inline function
  log_ref_setup(): separate code for create vs non-create
  log_ref_setup(): improve robustness against races
  log_ref_setup(): pass the open file descriptor back to the caller
  log_ref_write_1(): don't depend on logfile argument
  log_ref_setup(): manage the name of the reflog file internally
  log_ref_write_1(): inline function
  delete_ref_loose(): derive loose reference path from lock
  delete_ref_loose(): inline function
  try_remove_empty_parents(): rename parameter "name" -> "refname"
  try_remove_empty_parents(): don't trash argument contents
  try_remove_empty_parents(): don't accommodate consecutive slashes
  try_remove_empty_parents(): teach to remove parents of reflogs, too
  files_transaction_commit(): clean up empty directories
 cache.h               |  48 ++++++-
 refs/files-backend.c  | 375 +++++++++++++++++++++++++-------------------------
 refs/refs-internal.h  |  11 +-
 sha1_file.c           |  76 +++++++++-
 t/t1400-update-ref.sh |  27 ++++
 t/t5505-remote.sh     |   2 +-
 6 files changed, 346 insertions(+), 193 deletions(-)
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to refs/files-backend.c +1 −1
diff --git a/refs/files-backend.c b/refs/files-backend.c
index f902393..be4ffdc 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2631,7 +2631,7 @@ static int files_rename_ref(struct ref_store *ref_store,
 	if (!read_ref_full(newrefname, RESOLVE_REF_READING | RESOLVE_REF_NO_RECURSE,
 			   sha1, NULL) &&
 	    delete_ref(newrefname, NULL, REF_NODEREF)) {
-		if (errno==EISDIR) {
+		if (errno == EISDIR) {
 			struct strbuf path = STRBUF_INIT;
 			int result;
 
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 02/23] t5505: use "for-each-ref" to test for the non-existence of references

Instead of looking on the filesystem inside ".git/refs/remotes/origin", use "git for-each-ref" to check for leftover references under the remote's old name.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 t/t5505-remote.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to t/t5505-remote.sh +1 −1
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 8198d8e..65030fb 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -725,7 +725,7 @@ test_expect_success 'rename a remote' '
 	(
 		cd four &&
 		git remote rename origin upstream &&
-		rmdir .git/refs/remotes/origin &&
+		test -z "$(git for-each-ref refs/remotes/origin)" &&
 		test "$(git symbolic-ref refs/remotes/upstream/HEAD)" = "refs/remotes/upstream/master" &&
 		test "$(git rev-parse upstream/master)" = "$(git rev-parse master)" &&
 		test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*" &&
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 03/23] safe_create_leading_directories_const(): preserve errno

Some implementations of free() change errno (even thought they shouldn't):

  https://sourceware.org/bugzilla/show_bug.cgi?id=17924

So preserve the errno from safe_create_leading_directories() across the call to free().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 sha1_file.c | 4 ++++
 1 file changed, 4 insertions(+)
Show changes to sha1_file.c +4 −0
diff --git a/sha1_file.c b/sha1_file.c
index 1173071..10395e7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -166,10 +166,14 @@ enum scld_error safe_create_leading_directories(char *path)
 
 enum scld_error safe_create_leading_directories_const(const char *path)
 {
+	int save_errno;
 	/* path points to cache entries, so xstrdup before messing with it */
 	char *buf = xstrdup(path);
 	enum scld_error result = safe_create_leading_directories(buf);
+
+	save_errno = errno;
 	free(buf);
+	errno = save_errno;
 	return result;
 }
 
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 05/23] raceproof_create_file(): new function

Add a function that tries to create a file and any containing directories in a way that is robust against races with other processes that might be cleaning up empty directories at the same time.

The actual file creation is done by a callback function, which, if it fails, should set errno to EISDIR or ENOENT according to the convention of open(). raceproof_create_file() detects such failures, and respectively either tries to delete empty directories that might be in the way of the file or tries to create the containing directories. Then it retries the callback function.

This function is not yet used.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 cache.h     | 43 ++++++++++++++++++++++++++++++++++++++
 sha1_file.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 111 insertions(+)
Show changes to 2 files +111 −0

cache.h, sha1_file.c

diff --git a/cache.h b/cache.h
index 8177c3a..7bc4ea6 100644
--- a/cache.h
+++ b/cache.h
@@ -1057,6 +1057,49 @@ enum scld_error {
 enum scld_error safe_create_leading_directories(char *path);
 enum scld_error safe_create_leading_directories_const(const char *path);
 
+/*
+ * Callback function for raceproof_create_file(). This function is
+ * expected to do something that makes dirname(path) permanent despite
+ * the fact that other processes might be cleaning up empty
+ * directories at the same time. Usually it will create a file named
+ * path, but alternatively it could create another file in that
+ * directory, or even chdir() into that directory. The function should
+ * return 0 if the action was completed successfully. On error, it
+ * should return a nonzero result and set errno.
+ * raceproof_create_file() treats two errno values specially:
+ *
+ * - ENOENT -- dirname(path) does not exist. In this case,
+ *             raceproof_create_file() tries creating dirname(path)
+ *             (and any parent directories, if necessary) and calls
+ *             the function again.
+ *
+ * - EISDIR -- the file already exists and is a directory. In this
+ *             case, raceproof_create_file() deletes the directory
+ *             (recursively) if it is empty and calls the function
+ *             again.
+ *
+ * Any other errno causes raceproof_create_file() to fail with the
+ * callback's return value and errno.
+ *
+ * Obviously, this function should be OK with being called again if it
+ * fails with ENOENT or EISDIR. In other scenarios it will not be
+ * called again.
+ */
+typedef int create_file_fn(const char *path, void *cb);
+
+/*
+ * Create a file in dirname(path) by calling fn, creating leading
+ * directories if necessary. Retry a few times in case we are racing
+ * with another process that is trying to clean up the directory that
+ * contains path. See the documentation for create_file_fn for more
+ * details.
+ *
+ * Return the value and set the errno that resulted from the most
+ * recent call of fn. fn is always called at least once, and will be
+ * called more than once if it returns ENOENT or EISDIR.
+ */
+int raceproof_create_file(const char *path, create_file_fn fn, void *cb);
+
 int mkdir_in_gitdir(const char *path);
 extern char *expand_user_path(const char *path);
 const char *enter_repo(const char *path, int strict);
diff --git a/sha1_file.c b/sha1_file.c
index ae8f0b4..b08f54c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -179,6 +179,74 @@ enum scld_error safe_create_leading_directories_const(const char *path)
 	return result;
 }
 
+int raceproof_create_file(const char *path, create_file_fn fn, void *cb)
+{
+	/*
+	 * The number of times we will try to remove empty directories
+	 * in the way of path. This is only 1 because if another
+	 * process is racily creating directories that conflict with
+	 * us, we don't want to fight against them.
+	 */
+	int remove_directories_remaining = 1;
+
+	/*
+	 * The number of times that we will try to create the
+	 * directories containing path. We are willing to attempt this
+	 * more than once, because another process could be trying to
+	 * clean up empty directories at the same time as we are
+	 * trying to create them.
+	 */
+	int create_directories_remaining = 3;
+
+	/* A scratch copy of path, filled lazily if we need it: */
+	struct strbuf path_copy = STRBUF_INIT;
+
+	int ret, save_errno;
+
+	/* Sanity check: */
+	assert(*path);
+
+retry_fn:
+	ret = fn(path, cb);
+	save_errno = errno;
+	if (!ret)
+		goto out;
+
+	if (errno == EISDIR && remove_directories_remaining-- > 0) {
+		/*
+		 * A directory is in the way. Maybe it is empty; try
+		 * to remove it:
+		 */
+		if (!path_copy.len)
+			strbuf_addstr(&path_copy, path);
+
+		if (!remove_dir_recursively(&path_copy, REMOVE_DIR_EMPTY_ONLY))
+			goto retry_fn;
+	} else if (errno == ENOENT && create_directories_remaining-- > 0) {
+		/*
+		 * Maybe the containing directory didn't exist, or
+		 * maybe it was just deleted by a process that is
+		 * racing with us to clean up empty directories. Try
+		 * to create it:
+		 */
+		enum scld_error scld_result;
+
+		if (!path_copy.len)
+			strbuf_addstr(&path_copy, path);
+
+		do {
+			scld_result = safe_create_leading_directories(path_copy.buf);
+			if (scld_result == SCLD_OK)
+				goto retry_fn;
+		} while (scld_result == SCLD_VANISHED && create_directories_remaining-- > 0);
+	}
+
+out:
+	strbuf_release(&path_copy);
+	errno = save_errno;
+	return ret;
+}
+
 static void fill_sha1_path(struct strbuf *buf, const unsigned char *sha1)
 {
 	int i;
-- 
2.9.3
Jeff King· Dec 31, 2016, 06:11 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 05/23] raceproof_create_file(): new function

On Sat, Dec 31, 2016 at 04:12:45AM +0100, Michael Haggerty wrote:
Show 10 quoted lines
> Add a function that tries to create a file and any containing
> directories in a way that is robust against races with other processes
> that might be cleaning up empty directories at the same time.
> 
> The actual file creation is done by a callback function, which, if it
> fails, should set errno to EISDIR or ENOENT according to the convention
> of open(). raceproof_create_file() detects such failures, and
> respectively either tries to delete empty directories that might be in
> the way of the file or tries to create the containing directories. Then
> it retries the callback function.

This seems like a nice primitive, and the resulting change in patch 7 is very pleasant.

At first I was surprised that the callback did not take the more usual open(2) flags, which might make it easy to reuse a few basic callbacks. But I see that in most cases the actual opening is deep inside a higher level construct like the lockfile code, and anything beyond the "void *" callback parameter that you have would make that really awkward.

Show 20 quoted lines
> +/*
> + * Callback function for raceproof_create_file(). This function is
> + * expected to do something that makes dirname(path) permanent despite
> + * the fact that other processes might be cleaning up empty
> + * directories at the same time. Usually it will create a file named
> + * path, but alternatively it could create another file in that
> + * directory, or even chdir() into that directory. The function should
> + * return 0 if the action was completed successfully. On error, it
> + * should return a nonzero result and set errno.
> + * raceproof_create_file() treats two errno values specially:
> + *
> + * - ENOENT -- dirname(path) does not exist. In this case,
> + *             raceproof_create_file() tries creating dirname(path)
> + *             (and any parent directories, if necessary) and calls
> + *             the function again.
> + *
> + * - EISDIR -- the file already exists and is a directory. In this
> + *             case, raceproof_create_file() deletes the directory
> + *             (recursively) if it is empty and calls the function
> + *             again.
It took me a minute to figure out why EISDIR is recursive.

If we are trying to create "foo/bar/baz", we can only get EISDIR when "baz" exists and is a directory. I at first took your recursive to me that we delete it and "foo/bar" and "foo". Which is just silly and counterproductive.

But presumably you mean that we delete "foo/bar/baz/xyzzy", etc, up to "foo/bar/baz", provided they are all empty directories. I think your comment is probably OK and I was just being thick, but maybe stating it like:

  ...removes the directory if it is empty (and recursively any empty
  directories it contains) and calls the function again.

would be more clear. That is still leaving the definition of "empty" implied, but it's hopefully obvious from the context.

Show 18 quoted lines
> +int raceproof_create_file(const char *path, create_file_fn fn, void *cb)
> +{
> +	/*
> +	 * The number of times we will try to remove empty directories
> +	 * in the way of path. This is only 1 because if another
> +	 * process is racily creating directories that conflict with
> +	 * us, we don't want to fight against them.
> +	 */
> +	int remove_directories_remaining = 1;
> +
> +	/*
> +	 * The number of times that we will try to create the
> +	 * directories containing path. We are willing to attempt this
> +	 * more than once, because another process could be trying to
> +	 * clean up empty directories at the same time as we are
> +	 * trying to create them.
> +	 */
> +	int create_directories_remaining = 3;

We know that 3 is higher than 1, so we would not fight forever between writing "foo" and "foo/bar". That made me wonder if we could fight with other code. The obvious one would be try_remove_empty_parents() in files-backend.c, but it makes only a single attempt at each directory. So we should "win" against it short of weird cases (like somebody running "git pack-refs --prune" in a tight loop).

> [...the actual function logic...]
Nice. This looks very straightforward.
-Peff
Michael Haggerty· Dec 31, 2016, 07:42 UTC · re: Jeff King · lore

Re: [PATCH v3 05/23] raceproof_create_file(): new function

On 12/31/2016 07:11 AM, Jeff King wrote:
Show 40 quoted lines
> On Sat, Dec 31, 2016 at 04:12:45AM +0100, Michael Haggerty wrote:
>> [...]
>> +/*
>> + * Callback function for raceproof_create_file(). This function is
>> + * expected to do something that makes dirname(path) permanent despite
>> + * the fact that other processes might be cleaning up empty
>> + * directories at the same time. Usually it will create a file named
>> + * path, but alternatively it could create another file in that
>> + * directory, or even chdir() into that directory. The function should
>> + * return 0 if the action was completed successfully. On error, it
>> + * should return a nonzero result and set errno.
>> + * raceproof_create_file() treats two errno values specially:
>> + *
>> + * - ENOENT -- dirname(path) does not exist. In this case,
>> + *             raceproof_create_file() tries creating dirname(path)
>> + *             (and any parent directories, if necessary) and calls
>> + *             the function again.
>> + *
>> + * - EISDIR -- the file already exists and is a directory. In this
>> + *             case, raceproof_create_file() deletes the directory
>> + *             (recursively) if it is empty and calls the function
>> + *             again.
> 
> It took me a minute to figure out why EISDIR is recursive.
> 
> If we are trying to create "foo/bar/baz", we can only get EISDIR when
> "baz" exists and is a directory. I at first took your recursive to me
> that we delete it and "foo/bar" and "foo". Which is just silly and
> counterproductive.
> 
> But presumably you mean that we delete "foo/bar/baz/xyzzy", etc, up to
> "foo/bar/baz", provided they are all empty directories. I think your
> comment is probably OK and I was just being thick, but maybe stating it
> like:
> 
>   ...removes the directory if it is empty (and recursively any empty
>   directories it contains) and calls the function again.
> 
> would be more clear. That is still leaving the definition of "empty"
> implied, but it's hopefully obvious from the context.
Yes, that's clearer. I'll change it. Thanks!
> [...]
Michael
Junio C Hamano· Jan 1, 2017, 02:07 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 05/23] raceproof_create_file(): new function

Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 12 quoted lines
>> But presumably you mean that we delete "foo/bar/baz/xyzzy", etc, up to
>> "foo/bar/baz", provided they are all empty directories. I think your
>> comment is probably OK and I was just being thick, but maybe stating it
>> like:
>> 
>>   ...removes the directory if it is empty (and recursively any empty
>>   directories it contains) and calls the function again.
>> 
>> would be more clear. That is still leaving the definition of "empty"
>> implied, but it's hopefully obvious from the context.
>
> Yes, that's clearer. I'll change it. Thanks!
Thanks. Will tweak it in while queuing.
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 06/23] lock_ref_sha1_basic(): inline constant

`lflags` is set a single time then never changed, so just inline it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
Show changes to refs/files-backend.c +1 −2
diff --git a/refs/files-backend.c b/refs/files-backend.c
index be4ffdc..7d4658a 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2000,7 +2000,6 @@ static struct ref_lock *lock_ref_sha1_basic(struct files_ref_store *refs,
 	struct strbuf ref_file = STRBUF_INIT;
 	struct ref_lock *lock;
 	int last_errno = 0;
-	int lflags = LOCK_NO_DEREF;
 	int mustexist = (old_sha1 && !is_null_sha1(old_sha1));
 	int resolve_flags = RESOLVE_REF_NO_RECURSE;
 	int attempts_remaining = 3;
@@ -2083,7 +2082,7 @@ static struct ref_lock *lock_ref_sha1_basic(struct files_ref_store *refs,
 		goto error_return;
 	}
 
-	if (hold_lock_file_for_update(lock->lk, ref_file.buf, lflags) < 0) {
+	if (hold_lock_file_for_update(lock->lk, ref_file.buf, LOCK_NO_DEREF) < 0) {
 		last_errno = errno;
 		if (errno == ENOENT && --attempts_remaining > 0)
 			/*
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 07/23] lock_ref_sha1_basic(): use raceproof_create_file()

Instead of coding the retry loop inline, use raceproof_create_file() to make lock acquisition safe against directory creation/deletion races.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 35 +++++++++--------------------------
 1 file changed, 9 insertions(+), 26 deletions(-)
Show changes to refs/files-backend.c +9 −26
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 7d4658a..74de289 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -1985,6 +1985,13 @@ static int remove_empty_directories(struct strbuf *path)
 	return remove_dir_recursively(path, REMOVE_DIR_EMPTY_ONLY);
 }
 
+static int create_reflock(const char *path, void *cb)
+{
+	struct lock_file *lk = cb;
+
+	return hold_lock_file_for_update(lk, path, LOCK_NO_DEREF) < 0 ? -1 : 0;
+}
+
 /*
  * Locks a ref returning the lock on success and NULL on failure.
  * On failure errno is set to something meaningful.
@@ -2002,7 +2009,6 @@ static struct ref_lock *lock_ref_sha1_basic(struct files_ref_store *refs,
 	int last_errno = 0;
 	int mustexist = (old_sha1 && !is_null_sha1(old_sha1));
 	int resolve_flags = RESOLVE_REF_NO_RECURSE;
-	int attempts_remaining = 3;
 	int resolved;
 
 	assert_main_repository(&refs->base, "lock_ref_sha1_basic");
@@ -2067,35 +2073,12 @@ static struct ref_lock *lock_ref_sha1_basic(struct files_ref_store *refs,
 
 	lock->ref_name = xstrdup(refname);
 
- retry:
-	switch (safe_create_leading_directories_const(ref_file.buf)) {
-	case SCLD_OK:
-		break; /* success */
-	case SCLD_VANISHED:
-		if (--attempts_remaining > 0)
-			goto retry;
-		/* fall through */
-	default:
+	if (raceproof_create_file(ref_file.buf, create_reflock, lock->lk)) {
 		last_errno = errno;
-		strbuf_addf(err, "unable to create directory for '%s'",
-			    ref_file.buf);
+		unable_to_lock_message(ref_file.buf, errno, err);
 		goto error_return;
 	}
 
-	if (hold_lock_file_for_update(lock->lk, ref_file.buf, LOCK_NO_DEREF) < 0) {
-		last_errno = errno;
-		if (errno == ENOENT && --attempts_remaining > 0)
-			/*
-			 * Maybe somebody just deleted one of the
-			 * directories leading to ref_file.  Try
-			 * again:
-			 */
-			goto retry;
-		else {
-			unable_to_lock_message(ref_file.buf, errno, err);
-			goto error_return;
-		}
-	}
 	if (verify_lock(lock, old_sha1, mustexist, err)) {
 		last_errno = errno;
 		goto error_return;
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller

This function will most often be called by log_ref_write_1(), which wants to append to the reflog file. In that case, it is silly to close the file only for the caller to reopen it immediately. So, in the case that the file was opened, pass the open file descriptor back to the caller.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)
Show changes to refs/files-backend.c +22 −17
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 345f7c3..7f26cf8 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2719,19 +2719,23 @@ static int open_or_create_logfile(const char *path, void *cb)
 }
 
 /*
- * Create a reflog for a ref.  If force_create = 0, the reflog will
- * only be created for certain refs (those for which
- * should_autocreate_reflog returns non-zero.  Otherwise, create it
- * regardless of the ref name.  Fill in *err and return -1 on failure.
+ * Create a reflog for a ref. Store its path to *logfile. If
+ * force_create = 0, only create the reflog for certain refs (those
+ * for which should_autocreate_reflog returns non-zero). Otherwise,
+ * create it regardless of the reference name. If the logfile already
+ * existed or was created, return 0 and set *logfd to the file
+ * descriptor opened for appending to the file. If no logfile exists
+ * and we decided not to create one, return 0 and set *logfd to -1. On
+ * failure, fill in *err, set *logfd to -1, and return -1.
  */
-static int log_ref_setup(const char *refname, struct strbuf *logfile, struct strbuf *err, int force_create)
+static int log_ref_setup(const char *refname,
+			 struct strbuf *logfile, int *logfd,
+			 struct strbuf *err, int force_create)
 {
-	int logfd;
-
 	strbuf_git_path(logfile, "logs/%s", refname);
 
 	if (force_create || should_autocreate_reflog(refname)) {
-		if (raceproof_create_file(logfile->buf, open_or_create_logfile, &logfd)) {
+		if (raceproof_create_file(logfile->buf, open_or_create_logfile, logfd)) {
 			if (errno == ENOENT)
 				strbuf_addf(err, "unable to create directory for '%s': "
 					    "%s", logfile->buf, strerror(errno));
@@ -2745,8 +2749,8 @@ static int log_ref_setup(const char *refname, struct strbuf *logfile, struct str
 			return -1;
 		}
 	} else {
-		logfd = open(logfile->buf, O_APPEND | O_WRONLY, 0666);
-		if (logfd < 0) {
+		*logfd = open(logfile->buf, O_APPEND | O_WRONLY, 0666);
+		if (*logfd < 0) {
 			if (errno == ENOENT || errno == EISDIR) {
 				/*
 				 * The logfile doesn't already exist,
@@ -2762,10 +2766,8 @@ static int log_ref_setup(const char *refname, struct strbuf *logfile, struct str
 		}
 	}
 
-	if (logfd >= 0) {
+	if (*logfd >= 0)
 		adjust_shared_perm(logfile->buf);
-		close(logfd);
-	}
 
 	return 0;
 }
@@ -2776,11 +2778,14 @@ static int files_create_reflog(struct ref_store *ref_store,
 {
 	int ret;
 	struct strbuf sb = STRBUF_INIT;
+	int fd;
 
 	/* Check validity (but we don't need the result): */
 	files_downcast(ref_store, 0, "create_reflog");
 
-	ret = log_ref_setup(refname, &sb, err, force_create);
+	ret = log_ref_setup(refname, &sb, &fd, err, force_create);
+	if (fd >= 0)
+		close(fd);
 	strbuf_release(&sb);
 	return ret;
 }
@@ -2816,17 +2821,17 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
 			   struct strbuf *logfile, int flags,
 			   struct strbuf *err)
 {
-	int logfd, result, oflags = O_APPEND | O_WRONLY;
+	int logfd, result;
 
 	if (log_all_ref_updates < 0)
 		log_all_ref_updates = !is_bare_repository();
 
-	result = log_ref_setup(refname, logfile, err, flags & REF_FORCE_CREATE_REFLOG);
+	result = log_ref_setup(refname, logfile, &logfd, err,
+			       flags & REF_FORCE_CREATE_REFLOG);
 
 	if (result)
 		return result;
 
-	logfd = open(logfile->buf, oflags);
 	if (logfd < 0)
 		return 0;
 	result = log_ref_write_fd(logfd, old_sha1, new_sha1,
-- 
2.9.3
Jeff King· Dec 31, 2016, 06:32 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller

On Sat, Dec 31, 2016 at 04:12:53AM +0100, Michael Haggerty wrote:
Show 5 quoted lines
> This function will most often be called by log_ref_write_1(), which
> wants to append to the reflog file. In that case, it is silly to close
> the file only for the caller to reopen it immediately. So, in the case
> that the file was opened, pass the open file descriptor back to the
> caller.
Sounds like a much saner interface.
Show 18 quoted lines
>  /*
> - * Create a reflog for a ref.  If force_create = 0, the reflog will
> - * only be created for certain refs (those for which
> - * should_autocreate_reflog returns non-zero.  Otherwise, create it
> - * regardless of the ref name.  Fill in *err and return -1 on failure.
> + * Create a reflog for a ref. Store its path to *logfile. If
> + * force_create = 0, only create the reflog for certain refs (those
> + * for which should_autocreate_reflog returns non-zero). Otherwise,
> + * create it regardless of the reference name. If the logfile already
> + * existed or was created, return 0 and set *logfd to the file
> + * descriptor opened for appending to the file. If no logfile exists
> + * and we decided not to create one, return 0 and set *logfd to -1. On
> + * failure, fill in *err, set *logfd to -1, and return -1.
>   */
> -static int log_ref_setup(const char *refname, struct strbuf *logfile, struct strbuf *err, int force_create)
> +static int log_ref_setup(const char *refname,
> +			 struct strbuf *logfile, int *logfd,
> +			 struct strbuf *err, int force_create)

The return value is always "0" or "-1". It seems like it would be simpler to just return the descriptor instead of 0.

I guess that makes it hard to identify the case when we chose not to create a descriptor. I wonder if more "normal" semantics would be:

  1. ret >= 0: file existed or was created, and ret is the descriptor
  2. ret < 0, err is empty: we chose not to create
  3. ret < 0, err is non-empty: a real error

I dunno. This may just be bikeshedding, and I can live with it either way (especially because you documented it!).

-Peff
Michael Haggerty· Dec 31, 2016, 07:58 UTC · re: Jeff King · lore

Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller

On 12/31/2016 07:32 AM, Jeff King wrote:
Show 40 quoted lines
> On Sat, Dec 31, 2016 at 04:12:53AM +0100, Michael Haggerty wrote:
> 
>> This function will most often be called by log_ref_write_1(), which
>> wants to append to the reflog file. In that case, it is silly to close
>> the file only for the caller to reopen it immediately. So, in the case
>> that the file was opened, pass the open file descriptor back to the
>> caller.
> 
> Sounds like a much saner interface.
> 
>>  /*
>> - * Create a reflog for a ref.  If force_create = 0, the reflog will
>> - * only be created for certain refs (those for which
>> - * should_autocreate_reflog returns non-zero.  Otherwise, create it
>> - * regardless of the ref name.  Fill in *err and return -1 on failure.
>> + * Create a reflog for a ref. Store its path to *logfile. If
>> + * force_create = 0, only create the reflog for certain refs (those
>> + * for which should_autocreate_reflog returns non-zero). Otherwise,
>> + * create it regardless of the reference name. If the logfile already
>> + * existed or was created, return 0 and set *logfd to the file
>> + * descriptor opened for appending to the file. If no logfile exists
>> + * and we decided not to create one, return 0 and set *logfd to -1. On
>> + * failure, fill in *err, set *logfd to -1, and return -1.
>>   */
>> -static int log_ref_setup(const char *refname, struct strbuf *logfile, struct strbuf *err, int force_create)
>> +static int log_ref_setup(const char *refname,
>> +			 struct strbuf *logfile, int *logfd,
>> +			 struct strbuf *err, int force_create)
> 
> The return value is always "0" or "-1". It seems like it would be
> simpler to just return the descriptor instead of 0.
> 
> I guess that makes it hard to identify the case when we chose not to
> create a descriptor. I wonder if more "normal" semantics would be:
> 
>   1. ret >= 0: file existed or was created, and ret is the descriptor
> 
>   2. ret < 0, err is empty: we chose not to create
> 
>   3. ret < 0, err is non-empty: a real error

I don't like making callers read err to find out whether the call was successful, and I think we've been able to avoid that pattern so far.

Another alternative would be to make ret == -1 mean a real error and ret == -2 mean that we chose not to create the file. But that would be straying from the usual "-1 means error" interface of open(), so I wasn't fond of that idea either.

> I dunno. This may just be bikeshedding, and I can live with it either
> way (especially because you documented it!).

Let's see if anybody has a strong opinion about it; otherwise I'd rather leave it as is.

Michael
Jeff King· Dec 31, 2016, 17:58 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller

On Sat, Dec 31, 2016 at 08:58:43AM +0100, Michael Haggerty wrote:
Show 14 quoted lines
> > The return value is always "0" or "-1". It seems like it would be
> > simpler to just return the descriptor instead of 0.
> > 
> > I guess that makes it hard to identify the case when we chose not to
> > create a descriptor. I wonder if more "normal" semantics would be:
> > 
> >   1. ret >= 0: file existed or was created, and ret is the descriptor
> > 
> >   2. ret < 0, err is empty: we chose not to create
> > 
> >   3. ret < 0, err is non-empty: a real error
> 
> I don't like making callers read err to find out whether the call was
> successful, and I think we've been able to avoid that pattern so far.

I guess my mental model is that case 2 _is_ a failure, because we didn't open the reflog. It's just one that callers may want to distinguish from case 3, because it's probably a silent failure, not one we want to complain to the user about.

But whether that's accurate would depend on the callers. Looking at the callers, I think the immediate callers would be happier with this, but you probably would want to end up converting case 3 back to "return 0" out of files_log_ref_write().

Show 5 quoted lines
> > I dunno. This may just be bikeshedding, and I can live with it either
> > way (especially because you documented it!).
> 
> Let's see if anybody has a strong opinion about it; otherwise I'd rather
> leave it as is.
Sounds good.
-Peff
Junio C Hamano· Jan 1, 2017, 10:36 UTC · re: Jeff King · lore

Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller

Jeff King <peff@peff.net> writes:
Show 34 quoted lines
> On Sat, Dec 31, 2016 at 08:58:43AM +0100, Michael Haggerty wrote:
>
>> > The return value is always "0" or "-1". It seems like it would be
>> > simpler to just return the descriptor instead of 0.
>> > 
>> > I guess that makes it hard to identify the case when we chose not to
>> > create a descriptor. I wonder if more "normal" semantics would be:
>> > 
>> >   1. ret >= 0: file existed or was created, and ret is the descriptor
>> > 
>> >   2. ret < 0, err is empty: we chose not to create
>> > 
>> >   3. ret < 0, err is non-empty: a real error
>> 
>> I don't like making callers read err to find out whether the call was
>> successful, and I think we've been able to avoid that pattern so far.
>
> I guess my mental model is that case 2 _is_ a failure, because we didn't
> open the reflog. It's just one that callers may want to distinguish from
> case 3, because it's probably a silent failure, not one we want to
> complain to the user about.
>
> But whether that's accurate would depend on the callers. Looking at the
> callers, I think the immediate callers would be happier with this, but
> you probably would want to end up converting case 3 back to "return 0"
> out of files_log_ref_write().
>
>> > I dunno. This may just be bikeshedding, and I can live with it either
>> > way (especially because you documented it!).
>> 
>> Let's see if anybody has a strong opinion about it; otherwise I'd rather
>> leave it as is.
>
> Sounds good.

FWIW, in my mental model, 2. is not a failure ("we returned without creating new log because that is what was asked by the user"). A true failure case is "we wanted to open but couldn't".

The caller needs to be able to differentiate between these two cases because we get no usable fd out of the function in either case.

I agree that we could cram the error status and the file descriptor into a single return value as you two discussed, but I think what the patch chose to do is easier to use from the callers' point of view. The caller can switch between the codepath to give an error message and the non-error codepath based on the return value, and in the non-error codepath can choose what to do based on the value of logfd.

I do not mind "all negative values mean there is no fd" plus "some negative values are more special than others" convention, and if a patch did that from the beginning, I certainly would not suggest to rewrite it to use the "error status comes as a return value, file descriptor is an out parameter" convention; i.e. I personally do not see much difference either way, so...

Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 12/23] log_ref_setup(): improve robustness against races

Change log_ref_setup() to use raceproof_create_file() to create the new logfile. This makes it more robust against a race against another process that might be trying to clean up empty directories while we are trying to create a new logfile.

This also means that it will only call create_leading_directories() if open() fails, which should be a net win. Even in the cases where we are willing to create a new logfile, it will usually be the case that the logfile already exists, or if not then that the directory containing the logfile already exists. In such cases, we will save some work that was previously done unconditionally.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 41 ++++++++++++++++++-----------------------
 1 file changed, 18 insertions(+), 23 deletions(-)
Show changes to refs/files-backend.c +18 −23
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 47c7829..345f7c3 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2710,6 +2710,14 @@ static int commit_ref(struct ref_lock *lock)
 	return 0;
 }
 
+static int open_or_create_logfile(const char *path, void *cb)
+{
+	int *fd = cb;
+
+	*fd = open(path, O_APPEND | O_WRONLY | O_CREAT, 0666);
+	return (*fd < 0) ? -1 : 0;
+}
+
 /*
  * Create a reflog for a ref.  If force_create = 0, the reflog will
  * only be created for certain refs (those for which
@@ -2723,31 +2731,18 @@ static int log_ref_setup(const char *refname, struct strbuf *logfile, struct str
 	strbuf_git_path(logfile, "logs/%s", refname);
 
 	if (force_create || should_autocreate_reflog(refname)) {
-		if (safe_create_leading_directories(logfile->buf) < 0) {
-			strbuf_addf(err, "unable to create directory for '%s': "
-				    "%s", logfile->buf, strerror(errno));
-			return -1;
-		}
-		logfd = open(logfile->buf, O_APPEND | O_WRONLY | O_CREAT, 0666);
-		if (logfd < 0) {
-			if (errno == EISDIR) {
-				/*
-				 * The directory that is in the way might be
-				 * empty. Try to remove it.
-				 */
-				if (remove_empty_directories(logfile)) {
-					strbuf_addf(err, "there are still logs under "
-						    "'%s'", logfile->buf);
-					return -1;
-				}
-				logfd = open(logfile->buf, O_APPEND | O_WRONLY | O_CREAT, 0666);
-			}
-
-			if (logfd < 0) {
+		if (raceproof_create_file(logfile->buf, open_or_create_logfile, &logfd)) {
+			if (errno == ENOENT)
+				strbuf_addf(err, "unable to create directory for '%s': "
+					    "%s", logfile->buf, strerror(errno));
+			else if (errno == EISDIR)
+				strbuf_addf(err, "there are still logs under '%s'",
+					    logfile->buf);
+			else
 				strbuf_addf(err, "unable to append to '%s': %s",
 					    logfile->buf, strerror(errno));
-				return -1;
-			}
+
+			return -1;
 		}
 	} else {
 		logfd = open(logfile->buf, O_APPEND | O_WRONLY, 0666);
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create

The behavior of this function (especially how it handles errors) is quite different depending on whether we are willing to create the reflog vs. whether we are only trying to open an existing reflog. So separate the code paths.

This also simplifies the next steps.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 58 ++++++++++++++++++++++++++++++++++------------------
 1 file changed, 38 insertions(+), 20 deletions(-)
Show changes to refs/files-backend.c +38 −20
diff --git a/refs/files-backend.c b/refs/files-backend.c
index fd8a751..47c7829 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2718,45 +2718,63 @@ static int commit_ref(struct ref_lock *lock)
  */
 static int log_ref_setup(const char *refname, struct strbuf *logfile, struct strbuf *err, int force_create)
 {
-	int logfd, oflags = O_APPEND | O_WRONLY;
+	int logfd;
 
 	strbuf_git_path(logfile, "logs/%s", refname);
+
 	if (force_create || should_autocreate_reflog(refname)) {
 		if (safe_create_leading_directories(logfile->buf) < 0) {
 			strbuf_addf(err, "unable to create directory for '%s': "
 				    "%s", logfile->buf, strerror(errno));
 			return -1;
 		}
-		oflags |= O_CREAT;
-	}
-
-	logfd = open(logfile->buf, oflags, 0666);
-	if (logfd < 0) {
-		if (!(oflags & O_CREAT) && (errno == ENOENT || errno == EISDIR))
-			return 0;
+		logfd = open(logfile->buf, O_APPEND | O_WRONLY | O_CREAT, 0666);
+		if (logfd < 0) {
+			if (errno == EISDIR) {
+				/*
+				 * The directory that is in the way might be
+				 * empty. Try to remove it.
+				 */
+				if (remove_empty_directories(logfile)) {
+					strbuf_addf(err, "there are still logs under "
+						    "'%s'", logfile->buf);
+					return -1;
+				}
+				logfd = open(logfile->buf, O_APPEND | O_WRONLY | O_CREAT, 0666);
+			}
 
-		if (errno == EISDIR) {
-			if (remove_empty_directories(logfile)) {
-				strbuf_addf(err, "there are still logs under "
-					    "'%s'", logfile->buf);
+			if (logfd < 0) {
+				strbuf_addf(err, "unable to append to '%s': %s",
+					    logfile->buf, strerror(errno));
 				return -1;
 			}
-			logfd = open(logfile->buf, oflags, 0666);
 		}
-
+	} else {
+		logfd = open(logfile->buf, O_APPEND | O_WRONLY, 0666);
 		if (logfd < 0) {
-			strbuf_addf(err, "unable to append to '%s': %s",
-				    logfile->buf, strerror(errno));
-			return -1;
+			if (errno == ENOENT || errno == EISDIR) {
+				/*
+				 * The logfile doesn't already exist,
+				 * but that is not an error; it only
+				 * means that we won't write log
+				 * entries to it.
+				 */
+			} else {
+				strbuf_addf(err, "unable to append to '%s': %s",
+					    logfile->buf, strerror(errno));
+				return -1;
+			}
 		}
 	}
 
-	adjust_shared_perm(logfile->buf);
-	close(logfd);
+	if (logfd >= 0) {
+		adjust_shared_perm(logfile->buf);
+		close(logfd);
+	}
+
 	return 0;
 }
 
-
 static int files_create_reflog(struct ref_store *ref_store,
 			       const char *refname, int force_create,
 			       struct strbuf *err)
-- 
2.9.3
Jeff King· Dec 31, 2016, 06:26 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create

On Sat, Dec 31, 2016 at 04:12:51AM +0100, Michael Haggerty wrote:
Show 28 quoted lines
> +	} else {
> +		logfd = open(logfile->buf, O_APPEND | O_WRONLY, 0666);
>  		if (logfd < 0) {
> -			strbuf_addf(err, "unable to append to '%s': %s",
> -				    logfile->buf, strerror(errno));
> -			return -1;
> +			if (errno == ENOENT || errno == EISDIR) {
> +				/*
> +				 * The logfile doesn't already exist,
> +				 * but that is not an error; it only
> +				 * means that we won't write log
> +				 * entries to it.
> +				 */
> +			} else {
> +				strbuf_addf(err, "unable to append to '%s': %s",
> +					    logfile->buf, strerror(errno));
> +				return -1;
> +			}
>  		}
>  	}
>  
> -	adjust_shared_perm(logfile->buf);
> -	close(logfd);
> +	if (logfd >= 0) {
> +		adjust_shared_perm(logfile->buf);
> +		close(logfd);
> +	}
> +

Hmm. I would have thought in the existing-logfile case that we would not need to adjust_shared_perm(). But maybe we just do it anyway to pick up potentially-changed config.

I also had to double-take at this close(). Aren't we calling this function so we can actually write to the log? But I skipped ahead in your series and see you address that confusion. :)

-Peff
Michael Haggerty· Dec 31, 2016, 07:52 UTC · re: Jeff King · lore

Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create

On 12/31/2016 07:26 AM, Jeff King wrote:
Show 13 quoted lines
> On Sat, Dec 31, 2016 at 04:12:51AM +0100, Michael Haggerty wrote:
>> [...]
>> -	adjust_shared_perm(logfile->buf);
>> -	close(logfd);
>> +	if (logfd >= 0) {
>> +		adjust_shared_perm(logfile->buf);
>> +		close(logfd);
>> +	}
>> +
> 
> Hmm. I would have thought in the existing-logfile case that we would not
> need to adjust_shared_perm(). But maybe we just do it anyway to pick up
> potentially-changed config.

I didn't change this aspect of the code's behavior (though I also found it a bit surprising).

Another thing I considered was changing adjust_shared_perm() to adjust the file's permissions through the open file descriptor using fchmod(). But that function has a bunch of callers, and I didn't want to have to duplicate the code, nor did I have the energy to change all of its callers (if that would even make sense for all callers, which I doubt).

> [...]
Michael
Junio C Hamano· Jan 1, 2017, 03:28 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create

Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 8 quoted lines
> +			if (errno == ENOENT || errno == EISDIR) {
> +				/*
> +				 * The logfile doesn't already exist,
> +				 * but that is not an error; it only
> +				 * means that we won't write log
> +				 * entries to it.
> +				 */
> +			} else {
It may be valid C, but an
	{
		/*
		 * an empty block without any statement,
		 * not even a null statement.
		 */
	}

always makes me a bit nervous. Have a line with a semicolon without anything else (other than the indent) at the end and it will read nicer, at least to me.

Michael Haggerty· Jan 1, 2017, 08:45 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create

On 01/01/2017 04:28 AM, Junio C Hamano wrote:
Show 23 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> +			if (errno == ENOENT || errno == EISDIR) {
>> +				/*
>> +				 * The logfile doesn't already exist,
>> +				 * but that is not an error; it only
>> +				 * means that we won't write log
>> +				 * entries to it.
>> +				 */
>> +			} else {
> 
> It may be valid C, but an
> 
> 	{
> 		/*
> 		 * an empty block without any statement,
> 		 * not even a null statement.
> 		 */
> 	}
> 
> always makes me a bit nervous.  Have a line with a semicolon without
> anything else (other than the indent) at the end and it will read
> nicer, at least to me.

That's a form of superstition that I haven't encountered before ;-) but I'll change it.

Michael
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 15/23] log_ref_setup(): manage the name of the reflog file internally

Instead of writing the name of the reflog file into a strbuf that is supplied by the caller but not needed there, write it into a local temporary buffer and remove the strbuf parameter entirely.

And while we're adjusting the function signature, reorder the arguments to move the input parameters before the output parameters.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 69 ++++++++++++++++++++++++++--------------------------
 1 file changed, 34 insertions(+), 35 deletions(-)
Show changes to refs/files-backend.c +34 −35
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 5a96424..455652c 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2719,37 +2719,36 @@ static int open_or_create_logfile(const char *path, void *cb)
 }
 
 /*
- * Create a reflog for a ref. Store its path to *logfile. If
- * force_create = 0, only create the reflog for certain refs (those
- * for which should_autocreate_reflog returns non-zero). Otherwise,
- * create it regardless of the reference name. If the logfile already
- * existed or was created, return 0 and set *logfd to the file
- * descriptor opened for appending to the file. If no logfile exists
- * and we decided not to create one, return 0 and set *logfd to -1. On
- * failure, fill in *err, set *logfd to -1, and return -1.
+ * Create a reflog for a ref. If force_create = 0, only create the
+ * reflog for certain refs (those for which should_autocreate_reflog
+ * returns non-zero). Otherwise, create it regardless of the reference
+ * name. If the logfile already existed or was created, return 0 and
+ * set *logfd to the file descriptor opened for appending to the file.
+ * If no logfile exists and we decided not to create one, return 0 and
+ * set *logfd to -1. On failure, fill in *err, set *logfd to -1, and
+ * return -1.
  */
-static int log_ref_setup(const char *refname,
-			 struct strbuf *logfile, int *logfd,
-			 struct strbuf *err, int force_create)
+static int log_ref_setup(const char *refname, int force_create,
+			 int *logfd, struct strbuf *err)
 {
-	strbuf_git_path(logfile, "logs/%s", refname);
+	char *logfile = git_pathdup("logs/%s", refname);
 
 	if (force_create || should_autocreate_reflog(refname)) {
-		if (raceproof_create_file(logfile->buf, open_or_create_logfile, logfd)) {
+		if (raceproof_create_file(logfile, open_or_create_logfile, logfd)) {
 			if (errno == ENOENT)
 				strbuf_addf(err, "unable to create directory for '%s': "
-					    "%s", logfile->buf, strerror(errno));
+					    "%s", logfile, strerror(errno));
 			else if (errno == EISDIR)
 				strbuf_addf(err, "there are still logs under '%s'",
-					    logfile->buf);
+					    logfile);
 			else
 				strbuf_addf(err, "unable to append to '%s': %s",
-					    logfile->buf, strerror(errno));
+					    logfile, strerror(errno));
 
-			return -1;
+			goto error;
 		}
 	} else {
-		*logfd = open(logfile->buf, O_APPEND | O_WRONLY, 0666);
+		*logfd = open(logfile, O_APPEND | O_WRONLY, 0666);
 		if (*logfd < 0) {
 			if (errno == ENOENT || errno == EISDIR) {
 				/*
@@ -2760,34 +2759,39 @@ static int log_ref_setup(const char *refname,
 				 */
 			} else {
 				strbuf_addf(err, "unable to append to '%s': %s",
-					    logfile->buf, strerror(errno));
-				return -1;
+					    logfile, strerror(errno));
+				goto error;
 			}
 		}
 	}
 
 	if (*logfd >= 0)
-		adjust_shared_perm(logfile->buf);
+		adjust_shared_perm(logfile);
 
+	free(logfile);
 	return 0;
+
+error:
+	free(logfile);
+	return -1;
 }
 
 static int files_create_reflog(struct ref_store *ref_store,
 			       const char *refname, int force_create,
 			       struct strbuf *err)
 {
-	int ret;
-	struct strbuf sb = STRBUF_INIT;
 	int fd;
 
 	/* Check validity (but we don't need the result): */
 	files_downcast(ref_store, 0, "create_reflog");
 
-	ret = log_ref_setup(refname, &sb, &fd, err, force_create);
+	if (log_ref_setup(refname, force_create, &fd, err))
+		return -1;
+
 	if (fd >= 0)
 		close(fd);
-	strbuf_release(&sb);
-	return ret;
+
+	return 0;
 }
 
 static int log_ref_write_fd(int fd, const unsigned char *old_sha1,
@@ -2818,16 +2822,15 @@ static int log_ref_write_fd(int fd, const unsigned char *old_sha1,
 
 static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
 			   const unsigned char *new_sha1, const char *msg,
-			   struct strbuf *logfile, int flags,
-			   struct strbuf *err)
+			   int flags, struct strbuf *err)
 {
 	int logfd, result;
 
 	if (log_all_ref_updates < 0)
 		log_all_ref_updates = !is_bare_repository();
 
-	result = log_ref_setup(refname, logfile, &logfd, err,
-			       flags & REF_FORCE_CREATE_REFLOG);
+	result = log_ref_setup(refname, flags & REF_FORCE_CREATE_REFLOG,
+			       &logfd, err);
 
 	if (result)
 		return result;
@@ -2858,11 +2861,7 @@ int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
 			const unsigned char *new_sha1, const char *msg,
 			int flags, struct strbuf *err)
 {
-	struct strbuf sb = STRBUF_INIT;
-	int ret = log_ref_write_1(refname, old_sha1, new_sha1, msg, &sb, flags,
-				  err);
-	strbuf_release(&sb);
-	return ret;
+	return log_ref_write_1(refname, old_sha1, new_sha1, msg, flags, err);
 }
 
 /*
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 16/23] log_ref_write_1(): inline function

Now files_log_ref_write() doesn't do anything beyond call log_ref_write_1(), so inline the latter into the former.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)
Show changes to refs/files-backend.c +3 −10
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 455652c..a4e0de5 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2820,9 +2820,9 @@ static int log_ref_write_fd(int fd, const unsigned char *old_sha1,
 	return 0;
 }
 
-static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
-			   const unsigned char *new_sha1, const char *msg,
-			   int flags, struct strbuf *err)
+int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
+			const unsigned char *new_sha1, const char *msg,
+			int flags, struct strbuf *err)
 {
 	int logfd, result;
 
@@ -2857,13 +2857,6 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
 	return 0;
 }
 
-int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
-			const unsigned char *new_sha1, const char *msg,
-			int flags, struct strbuf *err)
-{
-	return log_ref_write_1(refname, old_sha1, new_sha1, msg, flags, err);
-}
-
 /*
  * Write sha1 into the open lockfile, then close the lockfile. On
  * errors, rollback the lockfile, fill in *err and
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 19/23] try_remove_empty_parents(): rename parameter "name" -> "refname"

This is the standard nomenclature.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
Show changes to refs/files-backend.c +4 −4
diff --git a/refs/files-backend.c b/refs/files-backend.c
index e81c8a9..0275c8d 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2282,13 +2282,13 @@ static int pack_if_possible_fn(struct ref_entry *entry, void *cb_data)
 
 /*
  * Remove empty parents, but spare refs/ and immediate subdirs.
- * Note: munges *name.
+ * Note: munges *refname.
  */
-static void try_remove_empty_parents(char *name)
+static void try_remove_empty_parents(char *refname)
 {
 	char *p, *q;
 	int i;
-	p = name;
+	p = refname;
 	for (i = 0; i < 2; i++) { /* refs/{heads,tags,...}/ */
 		while (*p && *p != '/')
 			p++;
@@ -2306,7 +2306,7 @@ static void try_remove_empty_parents(char *name)
 		if (q == p)
 			break;
 		*q = '\0';
-		if (rmdir(git_path("%s", name)))
+		if (rmdir(git_path("%s", refname)))
 			break;
 	}
 }
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:13 UTC · re: Michael Haggerty · lore

[PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents

It's bad manners and surprising and therefore error-prone.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)
Show changes to refs/files-backend.c +9 −7
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 0275c8d..af5a0e2 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2282,13 +2282,15 @@ static int pack_if_possible_fn(struct ref_entry *entry, void *cb_data)
 
 /*
  * Remove empty parents, but spare refs/ and immediate subdirs.
- * Note: munges *refname.
  */
-static void try_remove_empty_parents(char *refname)
+static void try_remove_empty_parents(const char *refname)
 {
+	struct strbuf buf = STRBUF_INIT;
 	char *p, *q;
 	int i;
-	p = refname;
+
+	strbuf_addstr(&buf, refname);
+	p = buf.buf;
 	for (i = 0; i < 2; i++) { /* refs/{heads,tags,...}/ */
 		while (*p && *p != '/')
 			p++;
@@ -2296,8 +2298,7 @@ static void try_remove_empty_parents(char *refname)
 		while (*p == '/')
 			p++;
 	}
-	for (q = p; *q; q++)
-		;
+	q = buf.buf + buf.len;
 	while (1) {
 		while (q > p && *q != '/')
 			q--;
@@ -2305,10 +2306,11 @@ static void try_remove_empty_parents(char *refname)
 			q--;
 		if (q == p)
 			break;
-		*q = '\0';
-		if (rmdir(git_path("%s", refname)))
+		strbuf_setlen(&buf, q - buf.buf);
+		if (rmdir(git_path("%s", buf.buf)))
 			break;
 	}
+	strbuf_release(&buf);
 }
 
 /* make sure nobody touched the ref, and unlink */
-- 
2.9.3
Jeff King· Dec 31, 2016, 06:40 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents

On Sat, Dec 31, 2016 at 04:13:00AM +0100, Michael Haggerty wrote:
> It's bad manners and surprising and therefore error-prone.
Agreed.

I wondered while reading your earlier patch whether the safe_create_leading_directories() function had the same problem, but it carefully replaces the NUL it inserts.

Show 9 quoted lines
> -static void try_remove_empty_parents(char *refname)
> +static void try_remove_empty_parents(const char *refname)
>  {
> +	struct strbuf buf = STRBUF_INIT;
>  	char *p, *q;
>  	int i;
> -	p = refname;
> +
> +	strbuf_addstr(&buf, refname);
I see here you just make a copy. I think it would be enough to do:
Show 9 quoted lines
> @@ -2305,10 +2306,11 @@ static void try_remove_empty_parents(char *refname)
>  			q--;
>  		if (q == p)
>  			break;
> -		*q = '\0';
> -		if (rmdir(git_path("%s", refname)))
> +		strbuf_setlen(&buf, q - buf.buf);
> +		if (rmdir(git_path("%s", buf.buf)))
>  			break;
  *q = '\0';
  r = rmdir(git_path("%s", refname));
  *q = '/';
  if (r)
          break;

or something. But I doubt the single allocation is breaking the bank, and it has the nice side effect that callers can pass in a const string (I didn't check yet whether that enables further cleanups).

-Peff
Michael Haggerty· Jan 2, 2017, 16:27 UTC · re: Jeff King · lore

Re: [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents

On 12/31/2016 07:40 AM, Jeff King wrote:
Show 42 quoted lines
> On Sat, Dec 31, 2016 at 04:13:00AM +0100, Michael Haggerty wrote:
> 
>> It's bad manners and surprising and therefore error-prone.
> 
> Agreed.
> 
> I wondered while reading your earlier patch whether the
> safe_create_leading_directories() function had the same problem, but it
> carefully replaces the NUL it inserts.
> 
>> -static void try_remove_empty_parents(char *refname)
>> +static void try_remove_empty_parents(const char *refname)
>>  {
>> +	struct strbuf buf = STRBUF_INIT;
>>  	char *p, *q;
>>  	int i;
>> -	p = refname;
>> +
>> +	strbuf_addstr(&buf, refname);
> 
> I see here you just make a copy. I think it would be enough to do:
> 
>> @@ -2305,10 +2306,11 @@ static void try_remove_empty_parents(char *refname)
>>  			q--;
>>  		if (q == p)
>>  			break;
>> -		*q = '\0';
>> -		if (rmdir(git_path("%s", refname)))
>> +		strbuf_setlen(&buf, q - buf.buf);
>> +		if (rmdir(git_path("%s", buf.buf)))
>>  			break;
> 
>   *q = '\0';
>   r = rmdir(git_path("%s", refname));
>   *q = '/';
> 
>   if (r)
>           break;
> 
> or something. But I doubt the single allocation is breaking the bank,
> and it has the nice side effect that callers can pass in a const string
> (I didn't check yet whether that enables further cleanups).

The last patch in the series passes ref_update::refname to this function, which is `const char *`. With your suggested change, either that member would have to be made non-const, or it would have to be cast to const at the `try_remove_empty_parents()` callsite.

Making the member non-const would be easy, though it loses a tiny bit of documentation and safety against misuse. Also, scribbling even temporarily over that member would mean that this code is not thread-safe (though it seems unlikely that we would ever bother making it multithreaded).

I think I prefer the current version because it loosens the coupling between this function and its callers. But I don't mind either way if somebody feels strongly about it.

As an aside, I wonder whether we would be discussing this at all if we had stack-allocated strbufs that could be used without allocating heap memory in the usual case.

Michael
Jeff King· Jan 2, 2017, 17:10 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents

On Mon, Jan 02, 2017 at 05:27:59PM +0100, Michael Haggerty wrote:
Show 18 quoted lines
> > or something. But I doubt the single allocation is breaking the bank,
> > and it has the nice side effect that callers can pass in a const string
> > (I didn't check yet whether that enables further cleanups).
> 
> The last patch in the series passes ref_update::refname to this
> function, which is `const char *`. With your suggested change, either
> that member would have to be made non-const, or it would have to be cast
> to const at the `try_remove_empty_parents()` callsite.
> 
> Making the member non-const would be easy, though it loses a tiny bit of
> documentation and safety against misuse. Also, scribbling even
> temporarily over that member would mean that this code is not
> thread-safe (though it seems unlikely that we would ever bother making
> it multithreaded).
> 
> I think I prefer the current version because it loosens the coupling
> between this function and its callers. But I don't mind either way if
> somebody feels strongly about it.
OK, let's take what you have here, then.
> As an aside, I wonder whether we would be discussing this at all if we
> had stack-allocated strbufs that could be used without allocating heap
> memory in the usual case.

I'm not sure. We still pay the memcpy(), though I don't know how substantial that is compared to an allocation. For these small strings, probably not very.

-Peff
Michael Haggerty· Dec 31, 2016, 03:13 UTC · re: Michael Haggerty · lore

[PATCH v3 22/23] try_remove_empty_parents(): teach to remove parents of reflogs, too

Add a new "flags" parameter that tells the function whether to remove empty parent directories of the loose reference file, of the reflog file, or both. The new functionality is not yet used.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)
Show changes to refs/files-backend.c +18 −6
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 397488e..2155acf 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2280,10 +2280,18 @@ static int pack_if_possible_fn(struct ref_entry *entry, void *cb_data)
 	return 0;
 }
 
+enum {
+	REMOVE_EMPTY_PARENTS_REF = 0x01,
+	REMOVE_EMPTY_PARENTS_REFLOG = 0x02
+};
+
 /*
- * Remove empty parents, but spare refs/ and immediate subdirs.
+ * Remove empty parent directories associated with the specified
+ * reference and/or its reflog, but spare [logs/]refs/ and immediate
+ * subdirs. flags is a combination of REMOVE_EMPTY_PARENTS_REF and/or
+ * REMOVE_EMPTY_PARENTS_REFLOG.
  */
-static void try_remove_empty_parents(const char *refname)
+static void try_remove_empty_parents(const char *refname, unsigned int flags)
 {
 	struct strbuf buf = STRBUF_INIT;
 	char *p, *q;
@@ -2298,7 +2306,7 @@ static void try_remove_empty_parents(const char *refname)
 			p++;
 	}
 	q = buf.buf + buf.len;
-	while (1) {
+	while (flags & (REMOVE_EMPTY_PARENTS_REF | REMOVE_EMPTY_PARENTS_REFLOG)) {
 		while (q > p && *q != '/')
 			q--;
 		if (q > p && *(q-1) == '/')
@@ -2306,8 +2314,12 @@ static void try_remove_empty_parents(const char *refname)
 		if (q == p)
 			break;
 		strbuf_setlen(&buf, q - buf.buf);
-		if (rmdir(git_path("%s", buf.buf)))
-			break;
+		if ((flags & REMOVE_EMPTY_PARENTS_REF) &&
+		    rmdir(git_path("%s", buf.buf)))
+			flags &= ~REMOVE_EMPTY_PARENTS_REF;
+		if ((flags & REMOVE_EMPTY_PARENTS_REFLOG) &&
+		    rmdir(git_path("logs/%s", buf.buf)))
+			flags &= ~REMOVE_EMPTY_PARENTS_REFLOG;
 	}
 	strbuf_release(&buf);
 }
@@ -2333,7 +2345,7 @@ static void prune_ref(struct ref_to_prune *r)
 	}
 	ref_transaction_free(transaction);
 	strbuf_release(&err);
-	try_remove_empty_parents(r->name);
+	try_remove_empty_parents(r->name, REMOVE_EMPTY_PARENTS_REF);
 }
 
 static void prune_refs(struct ref_to_prune *r)
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:13 UTC · re: Michael Haggerty · lore

[PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes

"refname" has already been checked by check_refname_format(), so it cannot have consecutive slashes.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
Show changes to refs/files-backend.c +2 −3
diff --git a/refs/files-backend.c b/refs/files-backend.c
index af5a0e2..397488e 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2294,15 +2294,14 @@ static void try_remove_empty_parents(const char *refname)
 	for (i = 0; i < 2; i++) { /* refs/{heads,tags,...}/ */
 		while (*p && *p != '/')
 			p++;
-		/* tolerate duplicate slashes; see check_refname_format() */
-		while (*p == '/')
+		if (*p == '/')
 			p++;
 	}
 	q = buf.buf + buf.len;
 	while (1) {
 		while (q > p && *q != '/')
 			q--;
-		while (q > p && *(q-1) == '/')
+		if (q > p && *(q-1) == '/')
 			q--;
 		if (q == p)
 			break;
-- 
2.9.3
Junio C Hamano· Jan 1, 2017, 02:30 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes

Michael Haggerty <mhagger@alum.mit.edu> writes:
> "refname" has already been checked by check_refname_format(), so it
> cannot have consecutive slashes.

In the endgame state, this has two callers. Both use what came in the transaction->updates[] array. Presumably "has already been checked by check_refname_format()" says that whoever created entries in that array must have called the function, but it would be helpful to be more explicit here.

Show 27 quoted lines
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  refs/files-backend.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index af5a0e2..397488e 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -2294,15 +2294,14 @@ static void try_remove_empty_parents(const char *refname)
>  	for (i = 0; i < 2; i++) { /* refs/{heads,tags,...}/ */
>  		while (*p && *p != '/')
>  			p++;
> -		/* tolerate duplicate slashes; see check_refname_format() */
> -		while (*p == '/')
> +		if (*p == '/')
>  			p++;
>  	}
>  	q = buf.buf + buf.len;
>  	while (1) {
>  		while (q > p && *q != '/')
>  			q--;
> -		while (q > p && *(q-1) == '/')
> +		if (q > p && *(q-1) == '/')
>  			q--;
>  		if (q == p)
>  			break;
Jeff King· Jan 1, 2017, 05:59 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes

On Sat, Dec 31, 2016 at 06:30:01PM -0800, Junio C Hamano wrote:
Show 10 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > "refname" has already been checked by check_refname_format(), so it
> > cannot have consecutive slashes.
> 
> In the endgame state, this has two callers.  Both use what came in
> the transaction->updates[] array.  Presumably "has already been
> checked by check_refname_format()" says that whoever created entries
> in that array must have called the function, but it would be helpful
> to be more explicit here.

Hmm, yeah. This is called when we are deleting a ref, and I thought we explicitly _didn't_ do check_refname_format() when deleting, so that funny-named refs could be deleted. It's only is_refname_safe() that we must pass.

So I have no idea if that's a problem in the code or not, but it is at least not immediately obvious who is responsible for calling check_refname_format() here.

-Peff
Michael Haggerty· Jan 2, 2017, 18:06 UTC · re: Jeff King · lore

Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes

On 01/01/2017 06:59 AM, Jeff King wrote:
Show 21 quoted lines
> On Sat, Dec 31, 2016 at 06:30:01PM -0800, Junio C Hamano wrote:
> 
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>>> "refname" has already been checked by check_refname_format(), so it
>>> cannot have consecutive slashes.
>>
>> In the endgame state, this has two callers.  Both use what came in
>> the transaction->updates[] array.  Presumably "has already been
>> checked by check_refname_format()" says that whoever created entries
>> in that array must have called the function, but it would be helpful
>> to be more explicit here.
> 
> Hmm, yeah. This is called when we are deleting a ref, and I thought we
> explicitly _didn't_ do check_refname_format() when deleting, so that
> funny-named refs could be deleted. It's only is_refname_safe() that we
> must pass.
> 
> So I have no idea if that's a problem in the code or not, but it is at
> least not immediately obvious who is responsible for calling
> check_refname_format() here.

My assumption was that only valid reference names should ever be allowed to be inserted into a `ref_transaction` entry. But Peff is right that sometimes the reference name is checked by `refname_is_safe()` rather than `check_refname_format()`. Let's audit this more carefully...

* `ref_transaction_add_update()` relies on its caller doing the check
  (this fact is documented). Its callers are:
  * `ref_transaction_update()` (the usual codepath), which checks the
    reference itself using either check_refname_format() or
    refname_is_safe() depending on what kind of update it is.
  * `split_head_update()` passes the literal string "HEAD".
  * `split_symref_update()` picks apart reference updates that go
    through existing symbolic references. As such I don't think they
    are an attack surface. It doesn't do any checking itself (here
    we're talking about its `referent` argument). It has only one
    caller:
    * `lock_ref_for_update()`, which gets `referent` from:
      * `files_read_raw_ref()`, which gets the value either:
        * by reading a filesystem-level symlink's contents and
          checking it with `check_refname_format()`, or
        * reading a symref from the filesystem. In this case, *the
          value is not checked*.

Obviously this chain of custody is disconcertingly long and complicated. And the gap for symrefs should probably be fixed, even though they are hopefully trustworthy.

`refname_is_safe()` checks that its argument is either UPPER_CASE or looks like a plausible filename under "refs/". Contrary to its docstring, it *does not* accept strings that contain successive slashes or "." or ".." components. It was made stricter in

    e40f355 "refname_is_safe(): insist that the refname already be
normalized", 2016-04-27
, but the docstring wasn't updated at that time. I'll fix it.

I think the best thing to do is to drop this patch from the patch series, and address these checks in a separate series. (There are more known problems in this area, for example that the checks in `check_refname_format()` are not a strict superset of the checks in `refname_is_safe()`.)

Michael
Jeff King· Jan 2, 2017, 18:26 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes

On Mon, Jan 02, 2017 at 07:06:32PM +0100, Michael Haggerty wrote:
Show 26 quoted lines
> My assumption was that only valid reference names should ever be allowed
> to be inserted into a `ref_transaction` entry. But Peff is right that
> sometimes the reference name is checked by `refname_is_safe()` rather
> than `check_refname_format()`. Let's audit this more carefully...
> 
> * `ref_transaction_add_update()` relies on its caller doing the check
>   (this fact is documented). Its callers are:
>   * `ref_transaction_update()` (the usual codepath), which checks the
>     reference itself using either check_refname_format() or
>     refname_is_safe() depending on what kind of update it is.
>   * `split_head_update()` passes the literal string "HEAD".
>   * `split_symref_update()` picks apart reference updates that go
>     through existing symbolic references. As such I don't think they
>     are an attack surface. It doesn't do any checking itself (here
>     we're talking about its `referent` argument). It has only one
>     caller:
>     * `lock_ref_for_update()`, which gets `referent` from:
>       * `files_read_raw_ref()`, which gets the value either:
>         * by reading a filesystem-level symlink's contents and
>           checking it with `check_refname_format()`, or
>         * reading a symref from the filesystem. In this case, *the
>           value is not checked*.
> 
> Obviously this chain of custody is disconcertingly long and complicated.
> And the gap for symrefs should probably be fixed, even though they are
> hopefully trustworthy.

Thanks as always for a careful analysis. I agree it seems like a bug that symlinks are checked but symrefs are not.

Show 5 quoted lines
> I think the best thing to do is to drop this patch from the patch
> series, and address these checks in a separate series. (There are more
> known problems in this area, for example that the checks in
> `check_refname_format()` are not a strict superset of the checks in
> `refname_is_safe()`.)

Sounds like a good plan. I'd be very happy if the "superset" mismatch is fixed. It seems like it has come up in our discussions more than once.

-Peff
Michael Haggerty· Dec 31, 2016, 03:13 UTC · re: Michael Haggerty · lore

[PATCH v3 23/23] files_transaction_commit(): clean up empty directories

When deleting/pruning references, remove any directories that are made empty by the deletion of loose references or of reflogs. Otherwise such empty directories can survive forever and accumulate over time. (Even 'pack-refs', which is smart enough to remove the parent directories of loose references that it prunes, leaves directories that were already empty.)

And now that files_transaction_commit() takes care of deleting the parent directories of loose references that it prunes, we don't have to do that in prune_ref() anymore.

This change would be unwise if the *creation* of these directories could race with our deletion of them. But the earlier changes in this patch series made the creation paths robust against races, so now it is safe to tidy them up more aggressively.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c  | 34 ++++++++++++++++++++++++++++------
 refs/refs-internal.h  | 11 +++++++++--
 t/t1400-update-ref.sh | 27 +++++++++++++++++++++++++++
 3 files changed, 64 insertions(+), 8 deletions(-)
Show changes to 3 files +64 −8

refs/files-backend.c, refs/refs-internal.h, t/t1400-update-ref.sh

diff --git a/refs/files-backend.c b/refs/files-backend.c
index 2155acf..26cfea3 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2345,7 +2345,6 @@ static void prune_ref(struct ref_to_prune *r)
 	}
 	ref_transaction_free(transaction);
 	strbuf_release(&err);
-	try_remove_empty_parents(r->name, REMOVE_EMPTY_PARENTS_REF);
 }
 
 static void prune_refs(struct ref_to_prune *r)
@@ -3792,6 +3791,7 @@ static int files_transaction_commit(struct ref_store *ref_store,
 					ret = TRANSACTION_GENERIC_ERROR;
 					goto cleanup;
 				}
+				update->flags |= REF_DELETED_LOOSE;
 			}
 
 			if (!(update->flags & REF_ISPRUNING))
@@ -3804,16 +3804,38 @@ static int files_transaction_commit(struct ref_store *ref_store,
 		ret = TRANSACTION_GENERIC_ERROR;
 		goto cleanup;
 	}
-	for_each_string_list_item(ref_to_delete, &refs_to_delete)
-		unlink_or_warn(git_path("logs/%s", ref_to_delete->string));
+
+	/* Delete the reflogs of any references that were deleted: */
+	for_each_string_list_item(ref_to_delete, &refs_to_delete) {
+		if (!unlink_or_warn(git_path("logs/%s", ref_to_delete->string)))
+			try_remove_empty_parents(ref_to_delete->string,
+						 REMOVE_EMPTY_PARENTS_REFLOG);
+	}
+
 	clear_loose_ref_cache(refs);
 
 cleanup:
 	transaction->state = REF_TRANSACTION_CLOSED;
 
-	for (i = 0; i < transaction->nr; i++)
-		if (transaction->updates[i]->backend_data)
-			unlock_ref(transaction->updates[i]->backend_data);
+	for (i = 0; i < transaction->nr; i++) {
+		struct ref_update *update = transaction->updates[i];
+		struct ref_lock *lock = update->backend_data;
+
+		if (lock)
+			unlock_ref(lock);
+
+		if (update->flags & REF_DELETED_LOOSE) {
+			/*
+			 * The loose reference was deleted. Delete any
+			 * empty parent directories. (Note that this
+			 * can only work because we have already
+			 * removed the lockfile.)
+			 */
+			try_remove_empty_parents(update->refname,
+						 REMOVE_EMPTY_PARENTS_REF);
+		}
+	}
+
 	string_list_clear(&refs_to_delete, 0);
 	free(head_ref);
 	string_list_clear(&affected_refnames, 0);
diff --git a/refs/refs-internal.h b/refs/refs-internal.h
index 708b260..de49362 100644
--- a/refs/refs-internal.h
+++ b/refs/refs-internal.h
@@ -56,6 +56,12 @@
 #define REF_UPDATE_VIA_HEAD 0x100
 
 /*
+ * Used as a flag in ref_update::flags when the loose reference has
+ * been deleted.
+ */
+#define REF_DELETED_LOOSE 0x200
+
+/*
  * Return true iff refname is minimally safe. "Safe" here means that
  * deleting a loose reference by this name will not do any damage, for
  * example by causing a file that is not a reference to be deleted.
@@ -157,8 +163,9 @@ struct ref_update {
 
 	/*
 	 * One or more of REF_HAVE_NEW, REF_HAVE_OLD, REF_NODEREF,
-	 * REF_DELETING, REF_ISPRUNING, REF_LOG_ONLY, and
-	 * REF_UPDATE_VIA_HEAD:
+	 * REF_DELETING, REF_ISPRUNING, REF_LOG_ONLY,
+	 * REF_UPDATE_VIA_HEAD, REF_NEEDS_COMMIT, and
+	 * REF_DELETED_LOOSE:
 	 */
 	unsigned int flags;
 
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index d4fb977..97d8793 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -191,6 +191,33 @@ test_expect_success \
 	 git update-ref HEAD'" $A &&
 	 test $A"' = $(cat .git/'"$m"')'
 
+test_expect_success "empty directory removal" '
+	git branch d1/d2/r1 HEAD &&
+	git branch d1/r2 HEAD &&
+	test -f .git/refs/heads/d1/d2/r1 &&
+	test -f .git/logs/refs/heads/d1/d2/r1 &&
+	git branch -d d1/d2/r1 &&
+	! test -e .git/refs/heads/d1/d2 &&
+	! test -e .git/logs/refs/heads/d1/d2 &&
+	test -f .git/refs/heads/d1/r2 &&
+	test -f .git/logs/refs/heads/d1/r2
+'
+
+test_expect_success "symref empty directory removal" '
+	git branch e1/e2/r1 HEAD &&
+	git branch e1/r2 HEAD &&
+	git checkout e1/e2/r1 &&
+	test_when_finished "git checkout master" &&
+	test -f .git/refs/heads/e1/e2/r1 &&
+	test -f .git/logs/refs/heads/e1/e2/r1 &&
+	git update-ref -d HEAD &&
+	! test -e .git/refs/heads/e1/e2 &&
+	! test -e .git/logs/refs/heads/e1/e2 &&
+	test -f .git/refs/heads/e1/r2 &&
+	test -f .git/logs/refs/heads/e1/r2 &&
+	test -f .git/logs/HEAD
+'
+
 cat >expect <<EOF
 $Z $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000	Initial Creation
 $A $B $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150260 +0000	Switch
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 04/23] safe_create_leading_directories(): set errno on SCLD_EXISTS

The exit path for SCLD_EXISTS wasn't setting errno, which some callers use to generate error messages for the user. Fix the problem and document that the function sets errno correctly to help avoid similar regressions in the future.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 cache.h     | 5 +++--
 sha1_file.c | 4 +++-
 2 files changed, 6 insertions(+), 3 deletions(-)
Show changes to 2 files +6 −3

cache.h, sha1_file.c

diff --git a/cache.h b/cache.h
index a50a61a..8177c3a 100644
--- a/cache.h
+++ b/cache.h
@@ -1031,8 +1031,9 @@ int adjust_shared_perm(const char *path);
 
 /*
  * Create the directory containing the named path, using care to be
- * somewhat safe against races.  Return one of the scld_error values
- * to indicate success/failure.
+ * somewhat safe against races. Return one of the scld_error values to
+ * indicate success/failure. On error, set errno to describe the
+ * problem.
  *
  * SCLD_VANISHED indicates that one of the ancestor directories of the
  * path existed at one point during the function call and then
diff --git a/sha1_file.c b/sha1_file.c
index 10395e7..ae8f0b4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -137,8 +137,10 @@ enum scld_error safe_create_leading_directories(char *path)
 		*slash = '\0';
 		if (!stat(path, &st)) {
 			/* path exists */
-			if (!S_ISDIR(st.st_mode))
+			if (!S_ISDIR(st.st_mode)) {
+				errno = ENOTDIR;
 				ret = SCLD_EXISTS;
+			}
 		} else if (mkdir(path, 0777)) {
 			if (errno == EEXIST &&
 			    !stat(path, &st) && S_ISDIR(st.st_mode))
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 08/23] rename_tmp_log(): use raceproof_create_file()

Besides shortening the code, this saves an unnecessary call to safe_create_leading_directories_const() in almost all cases.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 73 +++++++++++++++++++++-------------------------------
 1 file changed, 30 insertions(+), 43 deletions(-)
Show changes to refs/files-backend.c +30 −43
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 74de289..3f18a01 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2489,55 +2489,42 @@ static int files_delete_refs(struct ref_store *ref_store,
  */
 #define TMP_RENAMED_LOG  "logs/refs/.tmp-renamed-log"
 
-static int rename_tmp_log(const char *newrefname)
+static int rename_tmp_log_callback(const char *path, void *cb)
 {
-	int attempts_remaining = 4;
-	struct strbuf path = STRBUF_INIT;
-	int ret = -1;
+	int *true_errno = cb;
 
- retry:
-	strbuf_reset(&path);
-	strbuf_git_path(&path, "logs/%s", newrefname);
-	switch (safe_create_leading_directories_const(path.buf)) {
-	case SCLD_OK:
-		break; /* success */
-	case SCLD_VANISHED:
-		if (--attempts_remaining > 0)
-			goto retry;
-		/* fall through */
-	default:
-		error("unable to create directory for %s", newrefname);
-		goto out;
+	if (rename(git_path(TMP_RENAMED_LOG), path)) {
+		/*
+		 * rename(a, b) when b is an existing directory ought
+		 * to result in ISDIR, but Solaris 5.8 gives ENOTDIR.
+		 * Sheesh. Record the true errno for error reporting,
+		 * but report EISDIR to raceproof_create_file() so
+		 * that it knows to retry.
+		 */
+		*true_errno = errno;
+		if (errno == ENOTDIR)
+			errno = EISDIR;
+		return -1;
+	} else {
+		return 0;
 	}
+}
 
-	if (rename(git_path(TMP_RENAMED_LOG), path.buf)) {
-		if ((errno==EISDIR || errno==ENOTDIR) && --attempts_remaining > 0) {
-			/*
-			 * rename(a, b) when b is an existing
-			 * directory ought to result in ISDIR, but
-			 * Solaris 5.8 gives ENOTDIR.  Sheesh.
-			 */
-			if (remove_empty_directories(&path)) {
-				error("Directory not empty: logs/%s", newrefname);
-				goto out;
-			}
-			goto retry;
-		} else if (errno == ENOENT && --attempts_remaining > 0) {
-			/*
-			 * Maybe another process just deleted one of
-			 * the directories in the path to newrefname.
-			 * Try again from the beginning.
-			 */
-			goto retry;
-		} else {
+static int rename_tmp_log(const char *newrefname)
+{
+	char *path = git_pathdup("logs/%s", newrefname);
+	int ret, true_errno;
+
+	ret = raceproof_create_file(path, rename_tmp_log_callback, &true_errno);
+	if (ret) {
+		if (errno == EISDIR)
+			error("Directory not empty: %s", path);
+		else
 			error("unable to move logfile "TMP_RENAMED_LOG" to logs/%s: %s",
-				newrefname, strerror(errno));
-			goto out;
-		}
+				newrefname, strerror(true_errno));
 	}
-	ret = 0;
-out:
-	strbuf_release(&path);
+
+	free(path);
 	return ret;
 }
 
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument

It's unnecessary to pass a strbuf holding the reflog path up and down the call stack now that it is hardly needed by the callers. Remove the places where log_ref_write_1() uses it, in preparation for making it internal to log_ref_setup().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)
Show changes to refs/files-backend.c +8 −4
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 7f26cf8..5a96424 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2837,14 +2837,18 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
 	result = log_ref_write_fd(logfd, old_sha1, new_sha1,
 				  git_committer_info(0), msg);
 	if (result) {
-		strbuf_addf(err, "unable to append to '%s': %s", logfile->buf,
-			    strerror(errno));
+		int save_errno = errno;
+
+		strbuf_addf(err, "unable to append to '%s': %s",
+			    git_path("logs/%s", refname), strerror(save_errno));
 		close(logfd);
 		return -1;
 	}
 	if (close(logfd)) {
-		strbuf_addf(err, "unable to append to '%s': %s", logfile->buf,
-			    strerror(errno));
+		int save_errno = errno;
+
+		strbuf_addf(err, "unable to append to '%s': %s",
+			    git_path("logs/%s", refname), strerror(save_errno));
 		return -1;
 	}
 	return 0;
-- 
2.9.3
Jeff King· Dec 31, 2016, 06:35 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument

On Sat, Dec 31, 2016 at 04:12:54AM +0100, Michael Haggerty wrote:
Show 24 quoted lines
> It's unnecessary to pass a strbuf holding the reflog path up and down
> the call stack now that it is hardly needed by the callers. Remove the
> places where log_ref_write_1() uses it, in preparation for making it
> internal to log_ref_setup().
> 
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  refs/files-backend.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 7f26cf8..5a96424 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -2837,14 +2837,18 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
>  	result = log_ref_write_fd(logfd, old_sha1, new_sha1,
>  				  git_committer_info(0), msg);
>  	if (result) {
> -		strbuf_addf(err, "unable to append to '%s': %s", logfile->buf,
> -			    strerror(errno));
> +		int save_errno = errno;
> +
> +		strbuf_addf(err, "unable to append to '%s': %s",
> +			    git_path("logs/%s", refname), strerror(save_errno));

Hmm. This means the logic of "the path for a reflog is git_path(logs/%s)" is now replicated in several places. Which feels kind of like a backwards step. But I guess it is pretty well cemented in the concept of files-backend.c, and I do like the later cleanups that this allows.

-Peff
Michael Haggerty· Dec 31, 2016, 08:01 UTC · re: Jeff King · lore

Re: [PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument

On 12/31/2016 07:35 AM, Jeff King wrote:
Show 32 quoted lines
> On Sat, Dec 31, 2016 at 04:12:54AM +0100, Michael Haggerty wrote:
> 
>> It's unnecessary to pass a strbuf holding the reflog path up and down
>> the call stack now that it is hardly needed by the callers. Remove the
>> places where log_ref_write_1() uses it, in preparation for making it
>> internal to log_ref_setup().
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>>  refs/files-backend.c | 12 ++++++++----
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/refs/files-backend.c b/refs/files-backend.c
>> index 7f26cf8..5a96424 100644
>> --- a/refs/files-backend.c
>> +++ b/refs/files-backend.c
>> @@ -2837,14 +2837,18 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
>>  	result = log_ref_write_fd(logfd, old_sha1, new_sha1,
>>  				  git_committer_info(0), msg);
>>  	if (result) {
>> -		strbuf_addf(err, "unable to append to '%s': %s", logfile->buf,
>> -			    strerror(errno));
>> +		int save_errno = errno;
>> +
>> +		strbuf_addf(err, "unable to append to '%s': %s",
>> +			    git_path("logs/%s", refname), strerror(save_errno));
> 
> Hmm. This means the logic of "the path for a reflog is
> git_path(logs/%s)" is now replicated in several places. Which feels kind
> of like a backwards step. But I guess it is pretty well cemented in the
> concept of files-backend.c, and I do like the later cleanups that this
> allows.

This might end up in a helper function in the not-too-distant future for other reasons, but given that such code already appears multiple times, I didn't feel too guilty about it.

Michael
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 17/23] delete_ref_loose(): derive loose reference path from lock

It is simpler to derive the path to the file that must be deleted from "lock->ref_name" than from the lock_file object.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
Show changes to refs/files-backend.c +1 −4
diff --git a/refs/files-backend.c b/refs/files-backend.c
index a4e0de5..847af81 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2430,10 +2430,7 @@ static int delete_ref_loose(struct ref_lock *lock, int flag, struct strbuf *err)
 		 * loose.  The loose file name is the same as the
 		 * lockfile name, minus ".lock":
 		 */
-		char *loose_filename = get_locked_file_path(lock->lk);
-		int res = unlink_or_msg(loose_filename, err);
-		free(loose_filename);
-		if (res)
+		if (unlink_or_msg(git_path("%s", lock->ref_name), err))
 			return 1;
 	}
 	return 0;
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 18/23] delete_ref_loose(): inline function

It was hardly doing anything anymore, and had only one caller.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)
Show changes to refs/files-backend.c +7 −18
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 847af81..e81c8a9 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2421,21 +2421,6 @@ static int repack_without_refs(struct files_ref_store *refs,
 	return ret;
 }
 
-static int delete_ref_loose(struct ref_lock *lock, int flag, struct strbuf *err)
-{
-	assert(err);
-
-	if (!(flag & REF_ISPACKED) || flag & REF_ISSYMREF) {
-		/*
-		 * loose.  The loose file name is the same as the
-		 * lockfile name, minus ".lock":
-		 */
-		if (unlink_or_msg(git_path("%s", lock->ref_name), err))
-			return 1;
-	}
-	return 0;
-}
-
 static int files_delete_refs(struct ref_store *ref_store,
 			     struct string_list *refnames, unsigned int flags)
 {
@@ -3787,9 +3772,13 @@ static int files_transaction_commit(struct ref_store *ref_store,
 
 		if (update->flags & REF_DELETING &&
 		    !(update->flags & REF_LOG_ONLY)) {
-			if (delete_ref_loose(lock, update->type, err)) {
-				ret = TRANSACTION_GENERIC_ERROR;
-				goto cleanup;
+			if (!(update->type & REF_ISPACKED) ||
+			    update->type & REF_ISSYMREF) {
+				/* It is a loose reference. */
+				if (unlink_or_msg(git_path("%s", lock->ref_name), err)) {
+					ret = TRANSACTION_GENERIC_ERROR;
+					goto cleanup;
+				}
 			}
 
 			if (!(update->flags & REF_ISPRUNING))
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 09/23] rename_tmp_log(): improve error reporting

* Don't capitalize error strings
* Report true paths of affected files
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
Show changes to refs/files-backend.c +4 −3
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 3f18a01..49a119c 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2518,10 +2518,11 @@ static int rename_tmp_log(const char *newrefname)
 	ret = raceproof_create_file(path, rename_tmp_log_callback, &true_errno);
 	if (ret) {
 		if (errno == EISDIR)
-			error("Directory not empty: %s", path);
+			error("directory not empty: %s", path);
 		else
-			error("unable to move logfile "TMP_RENAMED_LOG" to logs/%s: %s",
-				newrefname, strerror(true_errno));
+			error("unable to move logfile %s to %s: %s",
+			      git_path(TMP_RENAMED_LOG), path,
+			      strerror(true_errno));
 	}
 
 	free(path);
-- 
2.9.3
Michael Haggerty· Dec 31, 2016, 03:12 UTC · re: Michael Haggerty · lore

[PATCH v3 10/23] log_ref_write(): inline function

This function doesn't do anything beyond call files_log_ref_write(), so replace it with the latter at its call sites.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
 refs/files-backend.c | 24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)
Show changes to refs/files-backend.c +10 −14
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 49a119c..fd8a751 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2832,14 +2832,6 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
 	return 0;
 }
 
-static int log_ref_write(const char *refname, const unsigned char *old_sha1,
-			 const unsigned char *new_sha1, const char *msg,
-			 int flags, struct strbuf *err)
-{
-	return files_log_ref_write(refname, old_sha1, new_sha1, msg, flags,
-				   err);
-}
-
 int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
 			const unsigned char *new_sha1, const char *msg,
 			int flags, struct strbuf *err)
@@ -2903,7 +2895,8 @@ static int commit_ref_update(struct files_ref_store *refs,
 	assert_main_repository(&refs->base, "commit_ref_update");
 
 	clear_loose_ref_cache(refs);
-	if (log_ref_write(lock->ref_name, lock->old_oid.hash, sha1, logmsg, 0, err)) {
+	if (files_log_ref_write(lock->ref_name, lock->old_oid.hash, sha1,
+				logmsg, 0, err)) {
 		char *old_msg = strbuf_detach(err, NULL);
 		strbuf_addf(err, "cannot update the ref '%s': %s",
 			    lock->ref_name, old_msg);
@@ -2934,7 +2927,7 @@ static int commit_ref_update(struct files_ref_store *refs,
 		if (head_ref && (head_flag & REF_ISSYMREF) &&
 		    !strcmp(head_ref, lock->ref_name)) {
 			struct strbuf log_err = STRBUF_INIT;
-			if (log_ref_write("HEAD", lock->old_oid.hash, sha1,
+			if (files_log_ref_write("HEAD", lock->old_oid.hash, sha1,
 					  logmsg, 0, &log_err)) {
 				error("%s", log_err.buf);
 				strbuf_release(&log_err);
@@ -2973,7 +2966,8 @@ static void update_symref_reflog(struct ref_lock *lock, const char *refname,
 	struct strbuf err = STRBUF_INIT;
 	unsigned char new_sha1[20];
 	if (logmsg && !read_ref(target, new_sha1) &&
-	    log_ref_write(refname, lock->old_oid.hash, new_sha1, logmsg, 0, &err)) {
+	    files_log_ref_write(refname, lock->old_oid.hash, new_sha1,
+				logmsg, 0, &err)) {
 		error("%s", err.buf);
 		strbuf_release(&err);
 	}
@@ -3748,9 +3742,11 @@ static int files_transaction_commit(struct ref_store *ref_store,
 
 		if (update->flags & REF_NEEDS_COMMIT ||
 		    update->flags & REF_LOG_ONLY) {
-			if (log_ref_write(lock->ref_name, lock->old_oid.hash,
-					  update->new_sha1,
-					  update->msg, update->flags, err)) {
+			if (files_log_ref_write(lock->ref_name,
+						lock->old_oid.hash,
+						update->new_sha1,
+						update->msg, update->flags,
+						err)) {
 				char *old_msg = strbuf_detach(err, NULL);
 
 				strbuf_addf(err, "cannot update the ref '%s': %s",
-- 
2.9.3
Junio C Hamano· Jan 1, 2017, 02:09 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 10/23] log_ref_write(): inline function

Michael Haggerty <mhagger@alum.mit.edu> writes:
> This function doesn't do anything beyond call files_log_ref_write(), so
s/call/&ing/; I think.
Show 70 quoted lines
> replace it with the latter at its call sites.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  refs/files-backend.c | 24 ++++++++++--------------
>  1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 49a119c..fd8a751 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -2832,14 +2832,6 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
>  	return 0;
>  }
>  
> -static int log_ref_write(const char *refname, const unsigned char *old_sha1,
> -			 const unsigned char *new_sha1, const char *msg,
> -			 int flags, struct strbuf *err)
> -{
> -	return files_log_ref_write(refname, old_sha1, new_sha1, msg, flags,
> -				   err);
> -}
> -
>  int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
>  			const unsigned char *new_sha1, const char *msg,
>  			int flags, struct strbuf *err)
> @@ -2903,7 +2895,8 @@ static int commit_ref_update(struct files_ref_store *refs,
>  	assert_main_repository(&refs->base, "commit_ref_update");
>  
>  	clear_loose_ref_cache(refs);
> -	if (log_ref_write(lock->ref_name, lock->old_oid.hash, sha1, logmsg, 0, err)) {
> +	if (files_log_ref_write(lock->ref_name, lock->old_oid.hash, sha1,
> +				logmsg, 0, err)) {
>  		char *old_msg = strbuf_detach(err, NULL);
>  		strbuf_addf(err, "cannot update the ref '%s': %s",
>  			    lock->ref_name, old_msg);
> @@ -2934,7 +2927,7 @@ static int commit_ref_update(struct files_ref_store *refs,
>  		if (head_ref && (head_flag & REF_ISSYMREF) &&
>  		    !strcmp(head_ref, lock->ref_name)) {
>  			struct strbuf log_err = STRBUF_INIT;
> -			if (log_ref_write("HEAD", lock->old_oid.hash, sha1,
> +			if (files_log_ref_write("HEAD", lock->old_oid.hash, sha1,
>  					  logmsg, 0, &log_err)) {
>  				error("%s", log_err.buf);
>  				strbuf_release(&log_err);
> @@ -2973,7 +2966,8 @@ static void update_symref_reflog(struct ref_lock *lock, const char *refname,
>  	struct strbuf err = STRBUF_INIT;
>  	unsigned char new_sha1[20];
>  	if (logmsg && !read_ref(target, new_sha1) &&
> -	    log_ref_write(refname, lock->old_oid.hash, new_sha1, logmsg, 0, &err)) {
> +	    files_log_ref_write(refname, lock->old_oid.hash, new_sha1,
> +				logmsg, 0, &err)) {
>  		error("%s", err.buf);
>  		strbuf_release(&err);
>  	}
> @@ -3748,9 +3742,11 @@ static int files_transaction_commit(struct ref_store *ref_store,
>  
>  		if (update->flags & REF_NEEDS_COMMIT ||
>  		    update->flags & REF_LOG_ONLY) {
> -			if (log_ref_write(lock->ref_name, lock->old_oid.hash,
> -					  update->new_sha1,
> -					  update->msg, update->flags, err)) {
> +			if (files_log_ref_write(lock->ref_name,
> +						lock->old_oid.hash,
> +						update->new_sha1,
> +						update->msg, update->flags,
> +						err)) {
>  				char *old_msg = strbuf_detach(err, NULL);
>  
>  				strbuf_addf(err, "cannot update the ref '%s': %s",
Michael Haggerty· Jan 1, 2017, 08:41 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 10/23] log_ref_write(): inline function

On 01/01/2017 03:09 AM, Junio C Hamano wrote:
Show 5 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> This function doesn't do anything beyond call files_log_ref_write(), so
> 
> s/call/&ing/; I think.
Thanks; will fix.
Michael
Jeff King· Dec 31, 2016, 06:47 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On Sat, Dec 31, 2016 at 04:12:40AM +0100, Michael Haggerty wrote:
Show 6 quoted lines
> This is a re-roll of an old patch series. v1 [1] got some feedback,
> which I think was all addressed in v2 [2]. But it seems that v2 fell
> on the floor, and I didn't bother following up because it was in the
> same area of code that was undergoing heavy changes due to the
> pluggable reference backend work. Sorry for the long delay before
> getting back to it.

I've read through the whole thing, and aside from a few very minor nits (that I am not even sure are worth a re-roll), I didn't see anything wrong. And the overall goal and approach seem obviously sound.

> Michael Haggerty (23):

I'll admit to being daunted by the number of patches, but it was quite a pleasant and easy read. Thanks.

-Peff
Junio C Hamano· Jan 1, 2017, 02:32 UTC · re: Jeff King · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> On Sat, Dec 31, 2016 at 04:12:40AM +0100, Michael Haggerty wrote:
>
>> This is a re-roll of an old patch series. v1 [1] got some feedback,
>> which I think was all addressed in v2 [2]. But it seems that v2 fell
>> on the floor, and I didn't bother following up because it was in the
>> same area of code that was undergoing heavy changes due to the
>> pluggable reference backend work. Sorry for the long delay before
>> getting back to it.
>
> I've read through the whole thing, and aside from a few very minor nits
> (that I am not even sure are worth a re-roll), I didn't see anything
> wrong. And the overall goal and approach seem obviously sound.
>
>> Michael Haggerty (23):
>
> I'll admit to being daunted by the number of patches, but it was quite a
> pleasant and easy read. Thanks.
>
> -Peff
Thanks, both.  These patches indeed were pleasant.
Jacob Keller· Jan 1, 2017, 09:24 UTC · re: Junio C Hamano · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On Sat, Dec 31, 2016 at 6:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> On Sat, Dec 31, 2016 at 04:12:40AM +0100, Michael Haggerty wrote:
>>
>>> This is a re-roll of an old patch series. v1 [1] got some feedback,
>>> which I think was all addressed in v2 [2]. But it seems that v2 fell
>>> on the floor, and I didn't bother following up because it was in the
>>> same area of code that was undergoing heavy changes due to the
>>> pluggable reference backend work. Sorry for the long delay before
>>> getting back to it.
>>
>> I've read through the whole thing, and aside from a few very minor nits
>> (that I am not even sure are worth a re-roll), I didn't see anything
>> wrong. And the overall goal and approach seem obviously sound.
>>
>>> Michael Haggerty (23):
>>
>> I'll admit to being daunted by the number of patches, but it was quite a
>> pleasant and easy read. Thanks.
>>
>> -Peff
>
> Thanks, both.  These patches indeed were pleasant.

I do have one comment regarding this series. Is it ever possible for an older version of git to be running a process while a new version of git which cleans up dirs runs? Is this expected? I just want to make sure we don't need to worry about that scenario since otherwise it makes it much more challenge.

My thought as far as I understand it is that it is possible, because a user COULD choose to run both this and an older version, but that it is unlikely in practice outside of a few developer boxes who periodically switch between versions of git, and are unlikely to actually run multiple versions at exactly the same time.

Thanks, Jake

Jacob Keller· Jan 1, 2017, 09:26 UTC · re: Jacob Keller · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On Sun, Jan 1, 2017 at 1:24 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
Show 39 quoted lines
> On Sat, Dec 31, 2016 at 6:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>> On Sat, Dec 31, 2016 at 04:12:40AM +0100, Michael Haggerty wrote:
>>>
>>>> This is a re-roll of an old patch series. v1 [1] got some feedback,
>>>> which I think was all addressed in v2 [2]. But it seems that v2 fell
>>>> on the floor, and I didn't bother following up because it was in the
>>>> same area of code that was undergoing heavy changes due to the
>>>> pluggable reference backend work. Sorry for the long delay before
>>>> getting back to it.
>>>
>>> I've read through the whole thing, and aside from a few very minor nits
>>> (that I am not even sure are worth a re-roll), I didn't see anything
>>> wrong. And the overall goal and approach seem obviously sound.
>>>
>>>> Michael Haggerty (23):
>>>
>>> I'll admit to being daunted by the number of patches, but it was quite a
>>> pleasant and easy read. Thanks.
>>>
>>> -Peff
>>
>> Thanks, both.  These patches indeed were pleasant.
>
> I do have one comment regarding this series. Is it ever possible for
> an older version of git to be running a process while a new version of
> git which cleans up dirs runs? Is this expected? I just want to make
> sure we don't need to worry about that scenario since otherwise it
> makes it much more challenge.
>
> My thought as far as I understand it is that it is possible, because a
> user COULD choose to run both this and an older version, but that it
> is unlikely in practice outside of a few developer boxes who
> periodically switch between versions of git, and are unlikely to
> actually run multiple versions at exactly the same time.
>
> Thanks,
> Jake

To add to this, if it is possible, it might be worth merging the "make ourselves safer against a race" first, and then waiting some time before merging the "we are now safe to delete directories". I am not yet convinced that it is necessary, but wanted to point it out so that someone more knowledgeable could explain why it is safe to do so.

Regards, Jake

Philip Oakley· Jan 1, 2017, 12:43 UTC · re: Jacob Keller · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

From: "Jacob Keller" <jacob.keller@gmail.com>
Sent: Sunday, January 01, 2017 9:24 AM
Show 30 quoted lines
> On Sat, Dec 31, 2016 at 6:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>> On Sat, Dec 31, 2016 at 04:12:40AM +0100, Michael Haggerty wrote:
>>>
>>>> This is a re-roll of an old patch series. v1 [1] got some feedback,
>>>> which I think was all addressed in v2 [2]. But it seems that v2 fell
>>>> on the floor, and I didn't bother following up because it was in the
>>>> same area of code that was undergoing heavy changes due to the
>>>> pluggable reference backend work. Sorry for the long delay before
>>>> getting back to it.
>>>
>>> I've read through the whole thing, and aside from a few very minor nits
>>> (that I am not even sure are worth a re-roll), I didn't see anything
>>> wrong. And the overall goal and approach seem obviously sound.
>>>
>>>> Michael Haggerty (23):
>>>
>>> I'll admit to being daunted by the number of patches, but it was quite a
>>> pleasant and easy read. Thanks.
>>>
>>> -Peff
>>
>> Thanks, both.  These patches indeed were pleasant.
>
> I do have one comment regarding this series. Is it ever possible for
> an older version of git to be running a process while a new version of
> git which cleans up dirs runs? Is this expected? I just want to make
> sure we don't need to worry about that scenario since otherwise it
> makes it much more challenge.

It is easily possible in the Windows environment where the install philosphy is different, and some external vendor tools may even bring in their own copy of Git as well. There is also the Portable Git version, so the possibility of multiple versions running concurrently is there, though it is on Windows...

I certainly have a Git-for-Windows published version, and a recent SDK version on my home machines.

Show 10 quoted lines
>
> My thought as far as I understand it is that it is possible, because a
> user COULD choose to run both this and an older version, but that it
> is unlikely in practice outside of a few developer boxes who
> periodically switch between versions of git, and are unlikely to
> actually run multiple versions at exactly the same time.
>
> Thanks,
> Jake
>
Philip 
Jacob Keller· Jan 1, 2017, 20:36 UTC · re: Philip Oakley · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On Sun, Jan 1, 2017 at 4:43 AM, Philip Oakley <philipoakley@iee.org> wrote:
Show 18 quoted lines
> From: "Jacob Keller" <jacob.keller@gmail.com>
>> I do have one comment regarding this series. Is it ever possible for
>> an older version of git to be running a process while a new version of
>> git which cleans up dirs runs? Is this expected? I just want to make
>> sure we don't need to worry about that scenario since otherwise it
>> makes it much more challenge.
>
>
> It is easily possible in the Windows environment where the install philosphy
> is different, and some external vendor tools may even bring in their own
> copy of Git as well. There is also the Portable Git version, so the
> possibility of multiple versions running concurrently is there, though it is
> on Windows...
>
> I certainly have a Git-for-Windows published version, and a recent SDK
> version on my home machines.
>
>
Ok.
Show 11 quoted lines
>>
>> My thought as far as I understand it is that it is possible, because a
>> user COULD choose to run both this and an older version, but that it
>> is unlikely in practice outside of a few developer boxes who
>> periodically switch between versions of git, and are unlikely to
>> actually run multiple versions at exactly the same time.
>>
>> Thanks,
>> Jake
>>
> Philip

But how likely is it to end up with differing binaries running on the exact same repository concurrently? Basically, I am trying to see whether or not we could accidentally end up causing problems by trying to race with other git processes that haven't yet been made safe against race? Is the worst case only that some git operation would fail and you would have to retry?

Thanks, Jake

Jeff King· Jan 2, 2017, 04:19 UTC · re: Jacob Keller · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On Sun, Jan 01, 2017 at 12:36:11PM -0800, Jacob Keller wrote:
Show 6 quoted lines
> But how likely is it to end up with differing binaries running on the
> exact same repository concurrently? Basically, I am trying to see
> whether or not we could accidentally end up causing problems by trying
> to race with other git processes that haven't yet been made safe
> against race? Is the worst case only that some git operation would
> fail and you would have to retry?
Yes, I think that is the worst case.

A more likely scenario might be something like a server accepting pushes or other ref updates from both JGit and regular git (or maybe libgit2 and regular git).

IMHO it's not really worth worrying about too much. Certain esoteric setups might have a slightly higher chance of a pretty obscure race condition happening on a very busy repository. I hate to say "eh, ship it, we'll see if anybody complains". But I'd be surprised to get a single report about this.

-Peff
Michael Haggerty· Jan 2, 2017, 18:14 UTC · re: Jeff King · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On 01/02/2017 05:19 AM, Jeff King wrote:
Show 20 quoted lines
> On Sun, Jan 01, 2017 at 12:36:11PM -0800, Jacob Keller wrote:
> 
>> But how likely is it to end up with differing binaries running on the
>> exact same repository concurrently? Basically, I am trying to see
>> whether or not we could accidentally end up causing problems by trying
>> to race with other git processes that haven't yet been made safe
>> against race? Is the worst case only that some git operation would
>> fail and you would have to retry?
> 
> Yes, I think that is the worst case.
> 
> A more likely scenario might be something like a server accepting pushes
> or other ref updates from both JGit and regular git (or maybe libgit2
> and regular git).
> 
> IMHO it's not really worth worrying about too much. Certain esoteric
> setups might have a slightly higher chance of a pretty obscure race
> condition happening on a very busy repository. I hate to say "eh, ship
> it, we'll see if anybody complains". But I'd be surprised to get a
> single report about this.

I agree. I think these races would mostly affect busy hosting sites and result in failed updates rather than corruption. And the races can already occur whenever the user runs `git pack-refs`. By contrast, the failure to delete empty directories is more likely to affect normal users.

That being said, if Junio wants to merge all but the last two patches in one release, then merge the last two a release or two later, I have no objections.

Michael
Jacob Keller· Jan 2, 2017, 18:54 UTC · re: Michael Haggerty · lore

Re: [PATCH v3 00/23] Delete directories left empty after ref deletion

On Mon, Jan 2, 2017 at 10:14 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 33 quoted lines
> On 01/02/2017 05:19 AM, Jeff King wrote:
>> On Sun, Jan 01, 2017 at 12:36:11PM -0800, Jacob Keller wrote:
>>
>>> But how likely is it to end up with differing binaries running on the
>>> exact same repository concurrently? Basically, I am trying to see
>>> whether or not we could accidentally end up causing problems by trying
>>> to race with other git processes that haven't yet been made safe
>>> against race? Is the worst case only that some git operation would
>>> fail and you would have to retry?
>>
>> Yes, I think that is the worst case.
>>
>> A more likely scenario might be something like a server accepting pushes
>> or other ref updates from both JGit and regular git (or maybe libgit2
>> and regular git).
>>
>> IMHO it's not really worth worrying about too much. Certain esoteric
>> setups might have a slightly higher chance of a pretty obscure race
>> condition happening on a very busy repository. I hate to say "eh, ship
>> it, we'll see if anybody complains". But I'd be surprised to get a
>> single report about this.
>
> I agree. I think these races would mostly affect busy hosting sites and
> result in failed updates rather than corruption. And the races can
> already occur whenever the user runs `git pack-refs`. By contrast, the
> failure to delete empty directories is more likely to affect normal users.
>
> That being said, if Junio wants to merge all but the last two patches in
> one release, then merge the last two a release or two later, I have no
> objections.
>
> Michael
>

I only wanted to make sure that the failure mode would not result in corruption. I believe that both you and Peff have alleviated my fears.

Thanks, Jake

← back to recent threads