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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jrnieder@gmail$(echo .)com \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=ramsay@ramsay1$(echo .)demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox