bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Dyballa
Subject: Re: Problems with directory trees "confdir-14B---" and "confdir3"
Date: Tue, 19 Mar 2024 23:32:27 +0100

> Am 19.03.2024 um 22:52 schrieb Paul Eggert <eggert@cs.ucla.edu>:
> 
> None of the traces you've sent reproduce the originally-reported problem of 
> "No space left on device". The latest trace instead shows:

Because *I* could not reproduce the circumstances. The confdir-14B-- tree might 
have had the same depth as in the original bug report, but the test programme 
can remove it. There exist obviously situations when it fails to remove its 
debris. It seems to depend on the whole length of pathname when the test 
programme either wants to remove the last created directory or it happens on 
its way up. The might exist a magic number in the length of pathname…

My work-around, years ago, was to patch the configure script changing 
"confdir-14B---" to "confdir-15B----". Now the test worked. The initial length 
is around 130–140 characters and slashes..

> My guess is that this old Mac OS X "rm" has corrupted internal memory 
> somehow. Let's not waste more time on it.

/bin/rm is not involved because the test programme is not using it but rmdir() 
when cleaning up…

> How about the following idea for old Mac OS X?
> 
> A. Build and install GNU coreutils first.
> 
> B. Put coreutils "rm" early in your PATH.
> 
> C. Build everything else.

Yes, the configure script could be patched to use grm in case the 
confdir-14B--- tree still exists, which would be a work-around.

--
Greetings

  Pete

There's no place like ~
                                – (UNIX Guru)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]