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

[Peter Dyballa]

> Am 18.03.2024 um 18:57 schrieb Paul Eggert <eggert@cs.ucla.edu>:
> 
> What's up with that "No space left on device" message?

I'd say that this is a misinterpretation. Mac OS X was not able to create a new 
subdirectory, so it said "No space left on device". When I saw this message I 
checked that I had enough disk space left – and I had a few GB left! It's a bit 
uncommon to create pathnames that extend the official PATH_MAX length, so no 
"specialised" error message is provided…

> Can you confirm that on macOS, an 'unlink' or 'rmdir' system call can fail 
> because you're out of disk space?

No, I cannot. I had situations with my old PowerBook G4 when this happened. 
Since I was logged in and usually have a root shell running I *could* remove 
core files manually and make the system work again.

If you can send me a programme that reads from /dev/null into some file until 
the disk is full and then tries system calls like unlink() I'd test it at once. 
Me, I would try to approach such a thing in many little and cautious steps 
which could take days.

> Kinda weird, huh? Does this have something to do with running the builds on a 
> file system that maintains histories of everything?

No. Apple's HFSX, I think that's the correct name, maintains a journal of meta 
data, it's a journaled FS. Previous versions of a file are not automatically 
kept (maybe except for the fact that it's Btrie based, i.e. the old leave is 
kept for later deletion while a new one is provided to reuse the file name or 
descriptor, if needed).

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

Correct, that's what we do observe at times, depending on not entirely known 
reasons.

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

Yes, this could work. Would need some testing with a single test programme. 
Performing this manually is a bit complicated when you have to handle strings 
of 1K length (and GNU Emacs *shell* allows only commands of length < 1K). My 
best effort was to *mv* the last few directories to /var/tmp and then remove 
the remaining tree (here) and that in /var/tmp.

Assume that the directory hierarchy reaches around 300 levels (or iterations in 
the for loop)!

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

Paul, it's a *historic Mac OS X* problem. Modern macOS seems to work better (or 
no-one was able to reproduce this – but I am working on it!).

--

Greetings

  Pete

A monsoon is a French gentleman.