archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <>
To: Jeff King <>
Cc: "brian m. carlson" <>,
	Jason Gore <>,
	"" <>
Subject: Re: Git clean enumerates ignored directories (since 2.27)
Date: Thu, 6 May 2021 20:44:57 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, May 6, 2021 at 8:25 PM Jeff King <> wrote:
> On Thu, May 06, 2021 at 07:31:40PM -0700, Elijah Newren wrote:
> > On alpine linux-musl, I get an "error: Tests passed but test cleanup
> > failed; aborting", which makes it report as a failed build.  I'm not
> > sure how to fix it and am asking for ideas.
> >
> > Apparently the deeply nested directory hierarchy cannot be removed on
> > that platform with a simple "rm -rf $dirname".  It throws a "rm: can't
> > stat '/__w/git/git/t/trash
> > directory.t7300-clean/avoid-traversing-deep-hierarchy/directory400/directory399/directory398/.....(you
> > get the idea)....': Filename too long" error message.[1]
> >
> > Adding a "test_when_finished find directory400 -delete" also gives a
> > "Filename too long" message followed by a lot of "Directory not empty"
> > messages.[2]
> >
> > Anyone have any bright ideas about how to tweak this test?  See [3]
> > for the current incarnation of the code, which was basically taken
> > from Brian's sample testcase.
> My guess is that that version of "rm" is trying to feed the entire
> pathname directly to unlink() and rmdir(), and it exceeds PATH_MAX.
> Even with GNU tools, for instance, I get:
>   $ rmdir $(find avoid-traversing-deep-hierarchy -type d | tail -1)
>   rmdir: failed to remove 'avoid-traversing-deep-hierarchy/directory400/
>     [...and so on...]/directory1': File name too long
> because it feeds the whole to a single rmdir() call. Whereas stracing
> GNU "rm -rf", it uses unlinkat() and openat() to delete each level
> individually (probably to avoid this exact problem).
> Is the actual path length important, or just the depth? If the latter,
> then calling it "d400/d399/.../d2/d1" would likely help, as that's less
> than 2000 bytes.

I needed some kind of way to notice and test that we had recursed into
the directory.  Excessively long paths trigger failures in open()
calls in git itself, which was the only marker I knew of.  So, I was
essentially depending on the long paths.  (The actual depth was not
important.). If there were a different way to determine whether we
recursed into the first level subdirectory, that'd be nicer.  I
thought about adding some trace2_region_enter/trace2_region_leave
calls and letting them nest up to whatever depth, though that seemed a
bit ugly.  I also thought about trying to determine the maximum
recursion level and seeing if that could be emitted via some kind of
trace2 magic, but that sounded like another rabbit hole.  In the end,
I gave up and used Brian's modification of Jason's testcase.

However, it looks like manually unstacking and deleting the directory
is going to work.  Incredibly ugly and slow, but adding the following
at the end of the testcase makes it work (at least on that platform,
still awaiting results on others):

    # alpine-linux-musl fails to "rm -rf" a directory with such
    # a deeply nested hierarchy.  Help it out by deleting the
    # leading directories ourselves.  Super slow, but, what else
    # can we do?  Without this, we will hit a
    #     error: Tests passed but test cleanup failed; aborting
    # so do this ugly manual cleanup...
    while test ! -f directory-random-file.txt; do
      name=$(ls -d directory*) &&
      mv $name/* . &&
      rmdir $name

      parent reply	other threads:[~2021-05-07  3:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 17:17 Jason Gore
2021-04-14 22:56 ` brian m. carlson
2021-04-15  8:51   ` Jeff King
2021-04-22 17:18     ` Jason Gore
2021-04-22 17:24       ` Elijah Newren
2021-05-07  4:08       ` Elijah Newren
2021-05-07  2:31     ` Elijah Newren
2021-05-07  3:25       ` Jeff King
2021-05-07  3:43         ` Jeff King
2021-05-07  3:44         ` Elijah Newren [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \
    --subject='Re: Git clean enumerates ignored directories (since 2.27)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).