Re: Problems with directory trees "confdir-14B---" and "confdir3"

[Paul Eggert]

Looking back at the original bug report 
<https://trac.macports.org/ticket/63603> I now see this weird line:

rm: 
confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---: 
No space left on device

What's up with that "No space left on device" message? Can you confirm 
that on macOS, an 'unlink' or 'rmdir' system call can fail because 
you're out of disk space? Kinda weird, huh? Does this have something to 
do with running the builds on a file system that maintains histories of 
everything?

When the Gnulib test fails, is there a directory "confdir-14B---" left 
behind such that "rm -rf confdir-14B---" does not remove it?

If not, then I'm not at all following what's going on.

If so, can we come up with some other command to remove that directory? 
Something like this, perhaps?

(cd confdir-14B---/confdir-14B--- && rm -fr *)
rm -fr confdir-14B---

If that works, it should be easy to change gnulib/m4/getcwd-abort-bug.m4 
to work around this macOS bug.