Delete directories left empty after ref deletion
v3 cover 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/[email protected]/T/#u
[2] http://public-inbox.org/git/[email protected]/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(-)
Signature · 1 line
2.9.3
PATCH v3 1/23 files_rename_ref(): tidy up whitespace
--- refs/files-backend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
refs/files-backend.c +1 -1
@@ -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;
Signature · 1 line
2.9.3
PATCH v3 2/23 t5505: use "for-each-ref" to test for the non-existence of references
In reply to Michael HaggertyInstead 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.
--- t/t5505-remote.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
t/t5505-remote.sh +1 -1
@@ -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/*" &&
Signature · 1 line
2.9.3
PATCH v3 3/23 safe_create_leading_directories_const(): preserve errno
In reply to Michael HaggertySome 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().
--- sha1_file.c | 4 ++++ 1 file changed, 4 insertions(+)
sha1_file.c +4 -0
@@ -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; }
Signature · 1 line
2.9.3
PATCH v3 4/23 safe_create_leading_directories(): set errno on SCLD_EXISTS
In reply to Michael HaggertyThe 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.
--- cache.h | 5 +++-- sha1_file.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-)
cache.h +3 -2
@@ -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
sha1_file.c +3 -1
@@ -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))
Signature · 1 line
2.9.3
PATCH v3 5/23 raceproof_create_file(): new function
In reply to Michael HaggertyAdd 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.
--- cache.h | 43 ++++++++++++++++++++++++++++++++++++++ sha1_file.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 111 insertions(+)
cache.h +43 -0
@@ -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);
sha1_file.c +68 -0
74 lines not on this page · raw message
Signature · 1 line
2.9.3
Re: [PATCH v3 05/23] raceproof_create_file(): new function
Quoted 10 lines · Michael Haggerty
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.
Quoted 12 lines
+/*
+ * Callback function forraceproof_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 evenchdir()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,
Quoted 8 lines
+ * 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.
Quoted 8 lines
sha1_file.c +8
-0+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. +*/
sha1_file.c enum scld_error safe_create_leading_directories_const(const char *path) · line 199
Quoted 10 lines
sha1_file.c +10
-0+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).
Quoted 1 line
[...the actual function logic...]
Nice. This looks very straightforward.
-Peff
Re: [PATCH v3 05/23] raceproof_create_file(): new function
Quoted 35 lines · Jeff King
Quoted 13 lines · Michael Haggerty
[...]
+/*
+ * Callback function forraceproof_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 evenchdir()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,Quoted 8 lines
+ * 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:
Quoted 5 lines
...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!
Quoted 1 line
[...]
Michael
Re: [PATCH v3 05/23] raceproof_create_file(): new function
Quoted 5 lines · Michael Haggerty
Quoted 5 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:
Quoted 7 lines
Quoted 5 lines
...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.
PATCH v3 6/23 lock_ref_sha1_basic(): inline constant
In reply to Michael Haggertylflags is set a single time then never changed, so just inline it.
--- refs/files-backend.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
refs/files-backend.c +1 -2
@@ -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 )/*
Signature · 1 line
2.9.3
PATCH v3 7/23 lock_ref_sha1_basic(): use raceproof_create_file()
In reply to Michael HaggertyInstead of coding the retry loop inline, use raceproof_create_file() to make lock acquisition safe against directory creation/deletion races.
--- refs/files-backend.c | 35 +++++++++-------------------------- 1 file changed, 9 insertions(+), 26 deletions(-)
refs/files-backend.c +9 -26
@@ -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;
Signature · 1 line
2.9.3
PATCH v3 8/23 rename_tmp_log(): use raceproof_create_file()
In reply to Michael HaggertyBesides shortening the code, this saves an unnecessary call to safe_create_leading_directories_const() in almost all cases.
--- refs/files-backend.c | 73 +++++++++++++++++++++------------------------------- 1 file changed, 30 insertions(+), 43 deletions(-)
refs/files-backend.c +30 -43
@@ -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; }
Signature · 1 line
2.9.3
PATCH v3 9/23 rename_tmp_log(): improve error reporting
In reply to Michael Haggerty* Don't capitalize error strings
* Report true paths of affected files
--- refs/files-backend.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
refs/files-backend.c +4 -3
@@ -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);
Signature · 1 line
2.9.3
PATCH v3 10/23 log_ref_write(): inline function
In reply to Michael HaggertyThis function doesn't do anything beyond call files_log_ref_write(), so replace it with the latter at its call sites.
--- refs/files-backend.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-)
refs/files-backend.c +10 -14
@@ -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",
Signature · 1 line
2.9.3
Re: [PATCH v3 10/23] log_ref_write(): inline function
Quoted 1 line · Michael Haggerty
This function doesn't do anything beyond call
files_log_ref_write(), so
s/call/&ing/; I think.
Quoted 70 lines
replace it with the latter at its call sites.
Signed-off-by Michael Haggerty <[email protected]>--- refs/files-backend.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-)refs/files-backend.c +10
-14@@ -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",
Re: [PATCH v3 10/23] log_ref_write(): inline function
Quoted 5 lines · Junio C Hamano
Quoted 1 line · Michael Haggerty
This function doesn't do anything beyond call
files_log_ref_write(), sos/call/&ing/; I think.
Thanks; will fix.
Michael
PATCH v3 11/23 log_ref_setup(): separate code for create vs non-create
In reply to Michael HaggertyThe 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.
--- refs/files-backend.c | 58 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 38 insertions(+), 20 deletions(-)
refs/files-backend.c +38 -20
@@ -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)
Signature · 1 line
2.9.3
Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create
Quoted 18 lines · Michael Haggerty
refs/files-backend.c +14
-3+ }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 ; + }
refs/files-backend.c static int commit_ref(struct ref_lock *lock) · line 2774
Quoted 10 lines
refs/files-backend.c +5
-2} } -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
Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create
Quoted 13 lines · Jeff King
refs/files-backend.c static int commit_ref(struct ref_lock *lock) · line 2774
Quoted 8 lines · Michael Haggerty
[...]
refs/files-backend.c +5
-2-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).
Quoted 1 line
[...]
Michael
Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create
In reply to Michael Haggertyrefs/files-backend.c static int commit_ref(struct ref_lock *lock) · line 2762
Quoted 8 lines · Michael Haggerty
refs/files-backend.c +8
-0+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.
Re: [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create
Quoted 20 lines · Junio C Hamano
refs/files-backend.c static int commit_ref(struct ref_lock *lock) · line 2762
Quoted 8 lines · Michael Haggerty
refs/files-backend.c +8
-0+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. */ }
Quoted 3 lines
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
PATCH v3 12/23 log_ref_setup(): improve robustness against races
In reply to Michael HaggertyChange 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.
--- refs/files-backend.c | 41 ++++++++++++++++++----------------------- 1 file changed, 18 insertions(+), 23 deletions(-)
refs/files-backend.c +18 -23
@@ -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 strstrbuf_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 );
Signature · 1 line
2.9.3
PATCH v3 13/23 log_ref_setup(): pass the open file descriptor back to the caller
In reply to Michael HaggertyThis 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.
--- refs/files-backend.c | 39 ++++++++++++++++++++++----------------- 1 file changed, 22 insertions(+), 17 deletions(-)
refs/files-backend.c +22 -17
@@ -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 strreturn -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,
Signature · 1 line
2.9.3
Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller
Quoted 5 lines · Michael Haggerty
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.
Quoted 14 lines
/*
- * Create a reflog for a ref. Ifforce_create= 0, the reflog will
- * only be created for certain refs (those for which
- *should_autocreate_reflogreturns 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 whichshould_autocreate_reflogreturns 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. */
refs/files-backend.c static int open_or_create_logfile(const char *path, void *cb) · line 2733
Quoted 4 lines
refs/files-backend.c +3
-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
Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller
Quoted 32 lines · Jeff King
Quoted 5 lines · Michael Haggerty
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.
Quoted 14 lines
/*
- * Create a reflog for a ref. Ifforce_create= 0, the reflog will
- * only be created for certain refs (those for which
- *should_autocreate_reflogreturns 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 whichshould_autocreate_reflogreturns 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. */refs/files-backend.c static int open_or_create_logfile(const char *path, void *cb) · line 2733
Quoted 4 lines
refs/files-backend.c +3
-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.
Quoted 8 lines
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.
Quoted 2 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.
Michael
Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller
Quoted 6 lines · Michael Haggerty
Quoted 6 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:
Quoted 8 lines
Quoted 5 lines
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().
Quoted 5 lines
Quoted 2 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
Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller
Quoted 27 lines · Jeff King
Quoted 6 lines · Michael Haggerty
Quoted 6 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:
Quoted 8 lines
Quoted 5 lines
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().
Quoted 7 lines
Quoted 5 lines
Quoted 2 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.
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...
PATCH v3 14/23 log_ref_write_1(): don't depend on logfile argument
In reply to Michael HaggertyIt'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().
--- refs/files-backend.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
refs/files-backend.c +8 -4
@@ -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 ;
Signature · 1 line
2.9.3
Re: [PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument
Quoted 15 lines · Michael Haggerty
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 tolog_ref_setup().Signed-off-by Michael Haggerty <[email protected]>--- refs/files-backend.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)refs/files-backend.c +0
-0
refs/files-backend.c static int log_ref_write_1(const char *refname, const unsigned char *old_sha1, · line 2843
Quoted 9 lines
refs/files-backend.c +4
-2@@ -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
Re: [PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument
Quoted 24 lines · Jeff King
Quoted 22 lines · Michael Haggerty
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 tolog_ref_setup().Signed-off-by Michael Haggerty <[email protected]>--- refs/files-backend.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)refs/files-backend.c +2
-2@@ -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; +
Quoted 8 lines
refs/files-backend.c static int log_ref_write_1(const char *refname, const unsigned char *old_sha1, · line 2843
Quoted 2 lines
refs/files-backend.c +2
-0+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 offiles-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
PATCH v3 15/23 log_ref_setup(): manage the name of the reflog file internally
In reply to Michael HaggertyInstead 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.
--- refs/files-backend.c | 69 ++++++++++++++++++++++++++-------------------------- 1 file changed, 34 insertions(+), 35 deletions(-)
refs/files-backend.c +34 -35
@@ -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); }/*
Signature · 1 line
2.9.3
PATCH v3 16/23 log_ref_write_1(): inline function
In reply to Michael HaggertyNow files_log_ref_write() doesn't do anything beyond call log_ref_write_1(), so inline the latter into the former.
--- refs/files-backend.c | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-)
refs/files-backend.c +3 -10
@@ -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
Signature · 1 line
2.9.3
PATCH v3 17/23 delete_ref_loose(): derive loose reference path from lock
In reply to Michael HaggertyIt is simpler to derive the path to the file that must be deleted from "lock->ref_name" than from the lock_file object.
--- refs/files-backend.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
refs/files-backend.c +1 -4
@@ -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 ;
Signature · 1 line
2.9.3
PATCH v3 18/23 delete_ref_loose(): inline function
In reply to Michael HaggertyIt was hardly doing anything anymore, and had only one caller.
--- refs/files-backend.c | 25 +++++++------------------ 1 file changed, 7 insertions(+), 18 deletions(-)
refs/files-backend.c +7 -18
@@ -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 ))
Signature · 1 line
2.9.3
PATCH v3 19/23 try_remove_empty_parents(): rename parameter "name" -> "refname"
In reply to Michael HaggertyThis is the standard nomenclature.
--- refs/files-backend.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
refs/files-backend.c +4 -4
@@ -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 ; } }
Signature · 1 line
2.9.3
PATCH v3 20/23 try_remove_empty_parents(): don't trash argument contents
In reply to Michael HaggertyIt's bad manners and surprising and therefore error-prone.
--- refs/files-backend.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
refs/files-backend.c +9 -7
@@ -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 */
Signature · 1 line
2.9.3
Re: [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents
Quoted 1 line · Michael Haggerty
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.
refs/files-backend.c static int pack_if_possible_fn(struct ref_entry *entry, void *cb_data) · line 2292
Quoted 9 lines
refs/files-backend.c +4
-2-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:
refs/files-backend.c static void try_remove_empty_parents(char *refname) · line 2311
Quoted 9 lines
refs/files-backend.c +2
-2@@ -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
Re: [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents
Quoted 36 lines · Jeff King
Quoted 1 line · Michael Haggerty
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.refs/files-backend.c static int pack_if_possible_fn(struct ref_entry *entry, void *cb_data) · line 2292
Quoted 9 lines
refs/files-backend.c +4
-2-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:
refs/files-backend.c static void try_remove_empty_parents(char *refname) · line 2311
Quoted 9 lines
refs/files-backend.c +2
-2@@ -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 = '/';
Quoted 6 lines
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
Re: [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents
Quoted 15 lines · Michael Haggerty
Quoted 3 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::refnameto this function, which isconst 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 thetry_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).
Quoted 3 lines
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.
Quoted 3 lines
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
PATCH v3 21/23 try_remove_empty_parents(): don't accommodate consecutive slashes
In reply to Michael Haggerty"refname" has already been checked by check_refname_format(), so it cannot have consecutive slashes.
--- refs/files-backend.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
refs/files-backend.c +2 -3
@@ -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 ;
Signature · 1 line
2.9.3
Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes
Quoted 2 lines · Michael Haggerty
"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.
Quoted 27 lines
Signed-off-by Michael Haggerty <[email protected]>--- refs/files-backend.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)refs/files-backend.c +2
-3@@ -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 ;
Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes
Quoted 10 lines · Junio C Hamano
Quoted 2 lines · Michael Haggerty
"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
Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes
Quoted 13 lines · Jeff King
Quoted 10 lines · Junio C Hamano
Quoted 2 lines · Michael Haggerty
"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.
Quoted 8 lines
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 onlyis_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
Re: [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes
Quoted 23 lines · Michael Haggerty
My assumption was that only valid reference names should ever be allowed to be inserted into a
ref_transactionentry. But Peff is right that sometimes the reference name is checked byrefname_is_safe()rather thancheck_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 eithercheck_refname_format()orrefname_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 itsreferentargument). It has only one caller:
*lock_ref_for_update(), which getsreferentfrom:
*files_read_raw_ref(), which gets the value either:
* by reading a filesystem-level symlink's contents and checking it withcheck_refname_format(), or
* reading a symref from the filesystem. In this case, *the value is not checked*.
Quoted 3 lines
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.
Quoted 5 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 inrefname_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
PATCH v3 22/23 try_remove_empty_parents(): teach to remove parents of reflogs, too
In reply to Michael HaggertyAdd 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.
--- refs/files-backend.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-)
refs/files-backend.c +18 -6
@@ -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)
Signature · 1 line
2.9.3
PATCH v3 23/23 files_transaction_commit(): clean up empty directories
In reply to Michael HaggertyWhen 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.
--- refs/files-backend.c | 34 ++++++++++++++++++++++++++++------ refs/refs-internal.h | 11 +++++++++-- t/t1400-update-ref.sh | 27 +++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 8 deletions(-)
refs/files-backend.c +28 -6
@@ -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 );
refs/refs-internal.h +9 -2
@@ -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;
t/t1400-update-ref.sh +27 -0
@@ -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
Signature · 1 line
2.9.3
Quoted 6 lines · Michael Haggerty
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.
Quoted 1 line
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
Quoted 13 lines · Jeff King
Quoted 6 lines · Michael Haggerty
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.
Quoted 6 lines
Quoted 1 line
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.
Quoted 15 lines · Junio C Hamano
Quoted 13 lines · Jeff King
Quoted 6 lines · Michael Haggerty
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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
Quoted 31 lines · Jacob Keller
Quoted 15 lines · Junio C Hamano
Quoted 13 lines · Jeff King
Quoted 6 lines · Michael Haggerty
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 8 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
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
From: "Jacob Keller" <[email protected]>
Sent: Sunday, January 01, 2017 9:24 AM
Quoted 23 lines · Junio C Hamano
Quoted 22 lines
Quoted 19 lines · Jeff King
Quoted 6 lines · Michael Haggerty
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.
Quoted 1 line
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
Quoted 7 lines
Quoted 1 line
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.
Quoted 10 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
Quoted 8 lines · Philip Oakley
From: "Jacob Keller" <[email protected]>
Quoted 5 lines
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.
Quoted 10 lines
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.
Quoted 11 lines
Quoted 10 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,
JakePhilip
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
Quoted 6 lines · Jacob Keller
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
Quoted 15 lines · Jeff King
Quoted 6 lines · Jacob Keller
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).
Quoted 5 lines
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
Quoted 27 lines · Michael Haggerty
Quoted 15 lines · Jeff King
Quoted 6 lines · Jacob Keller
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).
Quoted 5 lines
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.
Quoted 6 lines
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