> Am 18.03.2024 um 18:57 schrieb Paul Eggert <egg...@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.
