From: "Török Edwin" <edwintorok@gmail.com>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Fix 'git clean' failure on NFS.
Date: Fri, 18 Jun 2010 16:09:58 +0300 [thread overview]
Message-ID: <4C1B7026.2010501@gmail.com> (raw)
In-Reply-To: <4C1B63CB.7080209@viscovery.net>
On 06/18/2010 03:17 PM, Johannes Sixt wrote:
> Am 6/18/2010 13:07, schrieb Török Edwin:
>> else if (S_ISDIR(st.st_mode)) {
>> - if (!remove_dir_recursively(path, only_empty))
>> + if (!remove_dir_recursively(path, only_empty)) {
>> + did_rm = 1;
>> continue; /* happy */
>
> Is it possible that remove_dir_recursively exits with 0, but it actually
> did not remove the directory? That would result in an endless loop: it
> would have to re-enter remove_dir_recursively on the next iteration,
> return 0 again (without removing the directory), next iteration, etc.
Hmm, I think this could cause problems:
if ((flag & REMOVE_DIR_KEEP_NESTED_GIT) &&
!resolve_gitlink_ref(path->buf, "HEAD", submodule_head))
/* Do not descend and nuke a nested git work tree. */
return 0;
What if we limit the amount of times you can loop?
The worst case is that you loop == number of files in the directory, if
you loop more times than we could break out early.
Or we can compare the number of files listed in one pass, and in
another. If they stay equal, we can break out (since we'd infloop), if
it is higher (new files added) or lower (successfully removed some) we
can keep looping.
How does that sound?
--Edwin
next prev parent reply other threads:[~2010-06-18 13:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 14:26 [BUG] git clean not working on FreeBSD/NFS Török Edwin
2010-06-17 15:18 ` Henrik Grubbström
2010-06-18 11:03 ` Török Edwin
2010-06-18 11:07 ` [PATCH] Fix 'git clean' failure on NFS Török Edwin
2010-06-18 12:17 ` Johannes Sixt
2010-06-18 13:09 ` Török Edwin [this message]
2010-06-18 12:29 ` Erik Faye-Lund
2010-06-18 13:01 ` Török Edwin
2010-06-18 13:26 ` Erik Faye-Lund
2010-06-18 13:50 ` Török Edwin
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=4C1B7026.2010501@gmail.com \
--to=edwintorok@gmail.com \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).