From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
git@vger.kernel.org
Subject: Re: [PATCH v2 13/17] remove_dir_recurse(): handle disappearing files and directories
Date: Mon, 06 Jan 2014 10:18:58 -0800 [thread overview]
Message-ID: <xmqqy52tht2l.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1389015935-21936-14-git-send-email-mhagger@alum.mit.edu> (Michael Haggerty's message of "Mon, 6 Jan 2014 14:45:31 +0100")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> If a file or directory that we are trying to remove disappears (e.g.,
> because another process has pruned it), do not consider it an error.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> dir.c | 22 ++++++++++++++++------
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/dir.c b/dir.c
> index 11e1520..716b613 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1476,7 +1476,9 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
> flag &= ~REMOVE_DIR_KEEP_TOPLEVEL;
> dir = opendir(path->buf);
> if (!dir) {
> - if (errno == EACCES && !keep_toplevel)
> + if (errno == ENOENT)
> + return keep_toplevel ? -1 : 0;
If we were told that "foo/bar must go, but do not bother removing
foo/", is it an error if foo itself did not exist? I think this
step does not change the behaviour from the original (we used to say
"oh, we were told to keep_toplevel, and the top-level cannot be read
for whatever reason, so it is an error"), but because this series is
giving us a finer grained error diagnosis, we may want to think
about it further, perhaps as a follow-up.
I also wonder why the keep-toplevel logic is in this "recurse" part
of the callchain. If everything in "foo/bar/" can be removed but
"foo/bar/" is unreadable, it is OK, when opendir("foo/bar") failed
with EACCESS, to attempt to rmdir("foo/bar") whether we were told
not to attempt removing "foo/", no?
> + else if (errno == EACCES && !keep_toplevel)
That is, I am wondering why this part just checks !keep_toplevel,
not
(!keep_toplevel || has_dir_separator(path->buf))
or something.
> /*
> * An empty dir could be removable even if it
> * is unreadable:
> @@ -1496,13 +1498,21 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
>
> strbuf_setlen(path, len);
> strbuf_addstr(path, e->d_name);
> - if (lstat(path->buf, &st))
> - ; /* fall thru */
> - else if (S_ISDIR(st.st_mode)) {
> + if (lstat(path->buf, &st)) {
> + if (errno == ENOENT)
> + /*
> + * file disappeared, which is what we
> + * wanted anyway
> + */
> + continue;
> + /* fall thru */
> + } else if (S_ISDIR(st.st_mode)) {
> if (!remove_dir_recurse(path, flag, &kept_down))
> continue; /* happy */
> - } else if (!only_empty && !unlink(path->buf))
> + } else if (!only_empty &&
> + (!unlink(path->buf) || errno == ENOENT)) {
> continue; /* happy, too */
> + }
>
> /* path too long, stat fails, or non-directory still exists */
> ret = -1;
> @@ -1512,7 +1522,7 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
>
> strbuf_setlen(path, original_len);
> if (!ret && !keep_toplevel && !kept_down)
> - ret = rmdir(path->buf);
> + ret = (!rmdir(path->buf) || errno == ENOENT) ? 0 : -1;
> else if (kept_up)
> /*
> * report the uplevel that it is not an error that we
next prev parent reply other threads:[~2014-01-06 18:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 13:45 [PATCH v2 00/17] Fix some mkdir/rmdir races Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 01/17] safe_create_leading_directories(): fix format of "if" chaining Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 02/17] safe_create_leading_directories(): reduce scope of local variable Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 03/17] safe_create_leading_directories(): add explicit "slash" pointer Michael Haggerty
2014-01-06 18:32 ` Junio C Hamano
2014-01-07 9:26 ` Michael Haggerty
2014-01-07 17:41 ` Junio C Hamano
2014-01-19 20:31 ` Sebastian Schuberth
2014-01-06 13:45 ` [PATCH v2 04/17] safe_create_leading_directories(): rename local variable Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 05/17] safe_create_leading_directories(): split on first of multiple slashes Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 06/17] safe_create_leading_directories(): always restore slash at end of loop Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 07/17] safe_create_leading_directories(): introduce enum for return values Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 08/17] cmd_init_db(): when creating directories, handle errors conservatively Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 09/17] safe_create_leading_directories(): add new error value SCLD_VANISHED Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 10/17] lock_ref_sha1_basic(): on SCLD_VANISHED, retry Michael Haggerty
2014-01-06 17:54 ` Junio C Hamano
2014-01-07 10:25 ` Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 11/17] lock_ref_sha1_basic(): if locking fails with ENOENT, retry Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 12/17] remove_dir_recurse(): tighten condition for removing unreadable dir Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 13/17] remove_dir_recurse(): handle disappearing files and directories Michael Haggerty
2014-01-06 18:18 ` Junio C Hamano [this message]
2014-01-07 10:07 ` Michael Haggerty
2014-01-07 17:27 ` Junio C Hamano
2014-01-06 13:45 ` [PATCH v2 14/17] rename_ref(): extract function rename_tmp_log() Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 15/17] rename_tmp_log(): handle a possible mkdir/rmdir race Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 16/17] rename_tmp_log(): limit the number of remote_empty_directories() attempts Michael Haggerty
2014-01-06 13:45 ` [PATCH v2 17/17] rename_tmp_log(): on SCLD_VANISHED, retry Michael Haggerty
2014-01-06 18:21 ` Junio C Hamano
2014-01-07 10:50 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy52tht2l.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=ramsay@ramsay1.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.