Re: [Bug-tar] GNU Tar 1.28 configuration test for deep directory hierarc

Long slumber — apologies.

TL;DR — you may close this bug report. The original report was against Mac OS X El Capitan 10.11. Later versions of OS X 10.11 (definitively from 10.11.4, possibly earlier) have the problem fixed.

Gory details:

On 10.11.5, I ran the t.c file you provided and it worked cleanly. It exited with status 4, but there was no problem with the directory cleanup.

I still have a gruesome directory which 'Finder' (the OS X GUI tool) cannot clean up when it is in Trash. I've placed it into a directory $HOME/tmp/top-level and renamed 'confdir-14B---' to names such as 'confdir-000000' .. 'confdir-000335' (using the rename-it.sh script attached) I run into problems with 'confdir-000335'; although its mode field is 40700 (a directory with 700 permissions), I get errno 2 'no such file or directory' when I execute 'chdir("confdir-000335")' from directory "top-level/…/confdir-000334". I created a program do_cd.c (attached, along with the error reporting code I use, stderr.[ch]), loosely related to t.c that runs into a hard wall at level 335, whether run from top-level or from top-level/…/confdir-000129. The shell (Bash 3.2.57(1)) gives up (cannot do cd) after around top-level/…/confdir-000129, even trying 'cd top-level/…/confdir-000061' (successful) followed by 'cd confdir-000062/…/confdir-000129' (that succeeds, but 131 fails with 'path name too long').

I finally used 'cd top-level/…/confdir-000061; mv * ~/tmp/top-level' to move the hierarchy up the file system — so I had, briefly, top-level/confdir-000001 with a path down to confdir-000061, and top-level/confdir-000062 with a path down to confdir-000335. Running 'rm -fr confdir-000001' was able to clean that section up. Using do_cd, there were still problems with 'chdir("confdir-000335")' , but 'rm -fr confdir-000062' (from the ~/tmp/top-level directory) worked, so I finally don't have the wreckage of the attempted build cluttering up my file system.

I agree that what I found was a bug in OSX, and so apparently does Apple since the failure no longer occurs.

JFTR: the versions of Mac OS X 10.11.x El Capitan so far were announced in email on these dates:

10.11 — 2015-09-30
10.11.1 — 2015-10-21
10.11.2 — 2015-12-15
10.11.3 — 2016-01-19
10.11.4 — 2016-04-21
10.11.5 — 2016-05-16

Since I reported the problem on 2015-10-12, I must have been using 10.11 at the time, as I reported.

On Tue, Oct 13, 2015 at 11:39 AM, Paul Eggert <address@hidden> wrote:

On 10/12/2015 02:00 PM, Jonathan Leffler wrote:

1. Has anyone else seen anything similar on El Capitan?
2. Does anyone have an idea how to get rid of the trashed directories?
3. How can we modify the test so it doesn't fail catastrophically like this on El Capitan?
4. Do I need to report a bug to Apple separately from this report to GNU Tar?

For (4), OS X is clearly busted here. A user-mode application shouldn't be able to create a directory that 'rm -fr' can't remove. Please feel free to report the bug to Apple. The problem will occur with many GNU tools' installation procedure, as they're all using Gnulib and Gnulib tries to check for getcwd bugs like this one.

For (2) I suggest using coreutils; 'rm -fr directory should do the trick if you're using GNU rm.

For (3) we need to figure out why the test doesn't clean up after itself on El Capitan. It's supposed to. Please compile and run the attached test program in a place where you don't mind having long directory chains. On my GNU/Linux host, I can do something like this:

gcc t.c
strace ./a.out

and the 'strace' output contains the following, showing that the test program cleans up after itself. Please find out why it's not doing so under El Capitan. OS X lacks strace, but you can use a debugger or dtruss or whatever your favorite tool is. Thanks.

mkdir("confdir-14B---", 0700) = 0
chdir("confdir-14B---") = 0
mkdir("confdir-14B---", 0700) = 0
chdir("confdir-14B---") = 0
...
mkdir("confdir-14B---", 0700) = 0
chdir("confdir-14B---") = 0
getcwd(0x1736010, 4096) = -1 ENAMETOOLONG (File name too long)
[a whole bunch of other stuff, which eventually succeeds. Now comes cleanup time....]
rmdir("confdir-14B---") = -1 ENOENT (No such file or directory)
chdir("..") = 0
rmdir("confdir-14B---") = 0
chdir("..") = 0
...
chdir("..") = 0
rmdir("confdir-14B---") = 0
exit_group(0) = ?

Jonathan Leffler <address@hidden> #include <disclaimer.h>
Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

From:	Jonathan Leffler
Subject:	Re: [Bug-tar] GNU Tar 1.28 configuration test for deep directory hierarchy failing on Mac OS X 10.11 El Capitan
Date:	Sun, 5 Jun 2016 19:57:08 -0700