GNU bug report logs -
#78509
Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger
Previous Next
To reply to this bug, email your comments to 78509 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Tue, 20 May 2025 16:13:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Dyballa <Peter_Dyballa <at> Web.DE>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Tue, 20 May 2025 16:13:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello!
Working on a problem with diffutils 3.12 on the same platform (bug#77840) I see in the log file of the basic diffutils tests (with vi, because GNU Emacs has a problem with millions of NUL characters):
126 + mv k out
127 mv: cannot stat 'out/k': Not a directory
It comes from this test in diffutils-3.12/tests/basic:
33 echo a > a
34 echo b > b
35 for opt in '' -u -c; do
36 returns_ 1 diff $opt a b > out 2> err || fail=1
37 # Remove date and time.
38 sed -e 's/^\([-+*][-+*][-+*] [^ ]*\) .*/\1/' out > k; mv k out
39 compare exp-$(echo $opt|tr ' ' _) out || fail=1
40 done
Similarly on the command line (tcsh) this irregular behaviour can be observed:
pete 264 /\ gtouch a b
pete 265 /\ cp -v a b
a -> b
pete 266 /\ env LANG=C gcp -v a b
gcp: cannot stat 'b/a': Not a directory
Exit 1
pete 267 /\ gcp -v a ./c
'a' -> './c'
pete 268 /\ mv -v a b
a -> b
pete 269 /\ env LANG=C gmv -v b c
gmv: cannot stat 'c/b': Not a directory
Exit 1
pete 270 /\ env LANG=C gmv -v b ./c
gmv: cannot stat './c/b': Not a directory
Exit 1
pete 271 /\ env LANG=C gls -l a b c
gls: cannot access 'a': No such file or directory
-rw-r--r-- 1 pete wheel 0 May 20 17:47 b
-rw-r--r-- 1 pete wheel 0 May 20 17:47 c
Exit 2
pete 272 /\
--
Greetings
Pete
Theory and practice are the same, in theory, but, in practice, they are different.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Tue, 20 May 2025 17:11:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-20 09:12, Peter Dyballa via GNU coreutils Bug Reports wrote:
> 126 + mv k out
> 127 mv: cannot stat 'out/k': Not a directory
First, please build and run coreutils 9.7 and try that instead. If it
works, we're done. (For what it's worth, I just now built and ran
coreutils 9.7 on macOS 12.6 (ARM) and it worked fine.)
If the bug still occurs on your old platform with coreutils 9.7, please
reproduce the problem yourself, with something like this:
touch k out
mv k out
Once you've narrowed it down to something you can reproduce reliably,
please run 'mv' under a debugger to see why mv is incorrectly saying
"Not a directory".
On GNU/Linux, when I run 'strace mv k out', the trace contains the
following. Although macOS doesn't have strace (and its dtrace is so hard
to use and so flaky I don't recommend it), perhaps you can use this as a
guide for debugging mv under macOS. Notice that under GNU/Linux the
openat fails with "Not a directory" but that's OK: mv eventually figures
things out and does the renameat. Why isn't it doing something similar
on your macOS platform?
renameat2(AT_FDCWD, "k", AT_FDCWD, "out", RENAME_NOREPLACE) = -1 EEXIST
(File exists)
openat(AT_FDCWD, "out", O_RDONLY|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Not a
directory)
newfstatat(AT_FDCWD, "k", {st_mode=S_IFREG|0664, st_size=0, ...},
AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "out", {st_mode=S_IFREG|0664, st_size=0, ...},
AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 1000
faccessat2(AT_FDCWD, "out", W_OK, AT_EACCESS) = 0
renameat(AT_FDCWD, "k", AT_FDCWD, "out") = 0
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 21 May 2025 17:26:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 20.Mai.2025 um 19:10 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> First, please build and run coreutils 9.7 and try that instead. If it works, we're done. (For what it's worth, I just now built and ran coreutils 9.7 on macOS 12.6 (ARM) and it worked fine.)
They built! Tests do not succeed completely (details on demand):
>
> If the bug still occurs on your old platform with coreutils 9.7, please reproduce the problem yourself, with something like this:
>
> touch k out
> mv k out
>
> Once you've narrowed it down to something you can reproduce reliably, please run 'mv' under a debugger to see why mv is incorrectly saying "Not a directory".
tiger pete 226 /\ /opt/local/var/macports/build/_Volumes_BSD-Linux_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/src/touch k out
tiger pete 227 /\ !!:s:touch:mv:
/opt/local/var/macports/build/_Volumes_BSD-Linux_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7/src/mv k out
mv: cannot stat 'out/k': Not a directory
Exit 1
No trace here, only a ktrace (enable kernel process tracing), shall run "GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)" tomorrow.
--
Greetings
Pete
To be is to do.
– I. Kant
To do is to be.
– A. Sartre
Yabba-Dabba-Doo!
– F. Flintstone
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 21 May 2025 18:03:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 20.Mai.2025 um 19:10 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> First, please build and run coreutils 9.7 and try that instead.
Building with GCC 14.2 yields the same as reported before for diffutils 3.12, bug#77840:
/opt/local/bin/gcc-mp-14 -std=gnu23 -pipe -Os -arch ppc -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o src/hostid src/hostid.o src/libver.a lib/libcoreutils.a -lintl -Wl,-framework -Wl,CoreFoundation -Wl,-framework -Wl,CoreServices lib/libcoreutils.a
depbase=`echo src/timeout.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
/opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -pipe -Os -arch ppc -MT src/timeout.o -MD -MP -MF $depbase.Tpo -c -o src/timeout.o src/timeout.c &&\
mv -f $depbase.Tpo $depbase.Po
src/timeout.c: In function 'send_sig':
src/timeout.c:183:18: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types]
183 | signal (sig, SIG_IGN);
| ^~~~~~~
| |
| void (*)(void)
In file included from /usr/include/signal.h:63,
from ./lib/signal.h:52,
from /usr/include/sys/select.h:146,
from ./lib/sys/select.h:114,
from /usr/include/unistd.h:483,
from ./lib/unistd.h:40,
from /usr/include/getopt.h:44,
from ./lib/getopt.h:34,
from src/timeout.c:48:
/usr/include/sys/signal.h:419:23: note: expected 'void (*)(int)' but argument is of type 'void (*)(void)'
419 | void (*signal(int, void (*)(int)))(int);
| ^~~~~~~~~~~~~
src/timeout.c: In function 'main':
src/timeout.c:539:20: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types]
539 | signal (SIGTTIN, SIG_IGN); /* Don't stop if background child needs tty. */
| ^~~~~~~
| |
| void (*)(void)
/usr/include/sys/signal.h:419:23: note: expected 'void (*)(int)' but argument is of type 'void (*)(void)'
419 | void (*signal(int, void (*)(int)))(int);
| ^~~~~~~~~~~~~
src/timeout.c:540:20: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types]
540 | signal (SIGTTOU, SIG_IGN); /* Don't stop if background child needs tty. */
| ^~~~~~~
| |
| void (*)(void)
/usr/include/sys/signal.h:419:23: note: expected 'void (*)(int)' but argument is of type 'void (*)(void)'
419 | void (*signal(int, void (*)(int)))(int);
| ^~~~~~~~~~~~~
src/timeout.c:567:24: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types]
567 | signal (SIGTTIN, SIG_DFL);
| ^~~~~~~
| |
| void (*)(void)
/usr/include/sys/signal.h:419:23: note: expected 'void (*)(int)' but argument is of type 'void (*)(void)'
419 | void (*signal(int, void (*)(int)))(int);
| ^~~~~~~~~~~~~
src/timeout.c:568:24: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types]
568 | signal (SIGTTOU, SIG_DFL);
| ^~~~~~~
| |
| void (*)(void)
/usr/include/sys/signal.h:419:23: note: expected 'void (*)(int)' but argument is of type 'void (*)(void)'
419 | void (*signal(int, void (*)(int)))(int);
| ^~~~~~~~~~~~~
src/timeout.c:609:32: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types]
609 | signal (sig, SIG_DFL);
| ^~~~~~~
| |
| void (*)(void)
/usr/include/sys/signal.h:419:23: note: expected 'void (*)(int)' but argument is of type 'void (*)(void)'
419 | void (*signal(int, void (*)(int)))(int);
| ^~~~~~~~~~~~~
make[2]: *** [src/timeout.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_Volumes_BSD-Linux_macports-ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
Adding -Wincompatible-pointer-types to the C compiler flags does not change anything.
--
Mit friedvollen Grüßen
Pete
We've got to pause and ask ourselves: How much clean air do we need?
– Lee Iacocca
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 21 May 2025 19:14:04 GMT)
Full text and
rfc822 format available.
Message #17 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 20.Mai.2025 um 19:10 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> First, please build and run coreutils 9.7
The tests stop in
PASS: tests/cp/dir-vs-file.sh
PASS: tests/cp/existing-perm-dir.sh
at
+ mkfifo_or_skip_ fifo
+ test 1 = 1
+ mkfifo fifo
+ touch fifo-copy
+ chgrp 502 fifo
+ chgrp 262 fifo-copy
+ chmod g+r fifo-copy
+ cp -p --copy-contents fifo fifo-copy
+ pid=10841
cp: cannot stat 'fifo-copy/fifo': Not a directory
After waiting 40 min I had, at around 19:00 h:
-rw-r--r-- 1 macports admin 6677 21. Mai 18:25 existing-perm-race.log
-rw-r--r-- 1 macports admin 6194 21. Mai 18:25 existing-perm-dir.log
-rw-r--r-- 1 macports admin 82 21. Mai 18:25 existing-perm-dir.trs
Then, two hours ago, I killed 'make check'…
--
Greetings
Pete
My sister opened a computer store in Hawaii. She sells C shells down by the seashore.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 21 May 2025 20:47:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 21/05/2025 20:13, Peter Dyballa via GNU coreutils Bug Reports wrote:
>
>> Am 20.Mai.2025 um 19:10 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>>
>> First, please build and run coreutils 9.7
>
> The tests stop in
>
> PASS: tests/cp/dir-vs-file.sh
> PASS: tests/cp/existing-perm-dir.sh
>
> at
>
> + mkfifo_or_skip_ fifo
> + test 1 = 1
> + mkfifo fifo
> + touch fifo-copy
> + chgrp 502 fifo
> + chgrp 262 fifo-copy
> + chmod g+r fifo-copy
> + cp -p --copy-contents fifo fifo-copy
> + pid=10841
> cp: cannot stat 'fifo-copy/fifo': Not a directory
>
> After waiting 40 min I had, at around 19:00 h:
>
> -rw-r--r-- 1 macports admin 6677 21. Mai 18:25 existing-perm-race.log
> -rw-r--r-- 1 macports admin 6194 21. Mai 18:25 existing-perm-dir.log
> -rw-r--r-- 1 macports admin 82 21. Mai 18:25 existing-perm-dir.trs
>
> Then, two hours ago, I killed 'make check'…
I've not looked at the main issue at hand,
but the tests shouldn't hang. We already protect some
fifo interactions with `timeout 60`, so I've pushed this change
to avoid such hangs similarly in future:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=dc4e6b670
cheers,
Padraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 21 May 2025 21:03:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 21.Mai.2025 um 22:46 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> I've pushed this change
Some more changes might be useful: A few tests use the programme getent that neither exists in old Mac OS X nor in modern macOS… (same for diffutils, I think, I do remember a test which was logging that the user performing the tests is not unique/does not have a unique UID)
--
Greetings
Pete
The box said "Use Windows 95 or better," so I got a Macintosh.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 21 May 2025 21:11:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 21/05/2025 22:02, Peter Dyballa wrote:
>
>> Am 21.Mai.2025 um 22:46 schrieb Pádraig Brady <P <at> draigBrady.com>:
>>
>> I've pushed this change
>
> Some more changes might be useful: A few tests use the programme getent that neither exists in old Mac OS X nor in modern macOS… (same for diffutils, I think, I do remember a test which was logging that the user performing the tests is not unique/does not have a unique UID)
Yes I see getent is not available on macOS,
but for coreutils at least there is only a single test
that uses getent: tests/chown/separator.sh
and it seems to skip the test when getent is not available.
cheers,
Padraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 09:04:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 78509 <at> debbugs.gnu.org (full text, mbox):
Hello!
Here's a first result, got from using ktrace and kdump – and deleting almost ½ MB of text output:
17186 mv CALL geteuid
17186 mv RET geteuid 501/0x1f5
17186 mv CALL ioctl(0,0x4004667a ,0xbfffd498)
17186 mv RET ioctl 0
17186 mv CALL lstat(0xbfffd875,0xbfffcb28)
17186 mv NAMI "out"
17186 mv RET lstat 0
17186 mv CALL open(0xbfffd875,0x100000,0)
17186 mv NAMI "out"
17186 mv RET open 5
17186 mv CALL open(0x2a1dc,0x100004,0)
17186 mv NAMI "/proc/self/fd"
17186 mv RET open -1 errno 2 No such file or directory
17186 mv CALL stat(0x29410,0xbfffc790)
17186 mv NAMI "."
17186 mv RET stat 0
17186 mv CALL fstat(0x5,0xbfffc7f0)
17186 mv RET fstat 0
17186 mv CALL lstat(0xbfffd873,0xbfffd0e4)
17186 mv NAMI "k"
17186 mv RET lstat 0
17186 mv CALL open(0x29410,0,0)
17186 mv NAMI "."
17186 mv RET open 6
17186 mv CALL fcntl(0x6,0x1,0)
17186 mv RET fcntl 0
17186 mv CALL fcntl(0x6,0x2,0x1)
17186 mv RET fcntl 0
17186 mv CALL fchdir(0x5)
17186 mv RET fchdir -1 errno 20 Not a directory
17186 mv CALL close(0x6)
17186 mv RET close 0
Trying to open on Macs non-existent "/proc/self/fd" could cause a failure state suggesting mv to fchdir into a file, "out"…
--
Mit evolutionären Grüßen
Pete
"Evolution" o __o _o _
°\___o /0~ -\<, ^\___ /=\\_/-%
oo~_______ /\ /\______/ \_________O/ O_______________o===>-->O--o____
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 12:07:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 78509 <at> debbugs.gnu.org (full text, mbox):
Hello Pádraig!
> Am 21.Mai.2025 um 22:46 schrieb Pádraig Brady <P <at> draigBrady.com>:
>
> I've not looked at the main issue at hand,
> but the tests shouldn't hang. We already protect some
> fifo interactions with `timeout 60`, so I've pushed this change
> to avoid such hangs similarly in future:
> https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=dc4e6b670
I fetched your patch and let MacPorts apply it at start, which worked. I rebuilt coreutils with -ggdb -gdwarf-2 in order to be able to debug with Gdb, while 'make check' was running in the background. But, the applied patch was gone then, so I killed 'make check'. And I could apply your patch once more manually…
The tests have started again – and I am leaving now for some recreation… (am an old man)
--
Greetings
Pete
Either this man is dead or my watch has stopped.
- Groucho Marx
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 13:41:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 78509 <at> debbugs.gnu.org (full text, mbox):
After returning home 'make check' is frozen at:
PASS: tests/cp/cp-parents.sh
FAIL: tests/cp/debug.sh
FAIL: tests/cp/deref-slink.sh
PASS: tests/cp/dir-rm-dest.sh
PASS: tests/cp/dir-slash.sh
PASS: tests/cp/dir-vs-file.sh
PASS: tests/cp/existing-perm-dir.sh
The directory .../tests/cp has (a bit edited):
-rw-r--r-- 1 macports admin 6687 Mai 22 14:21 existing-perm-race.log
-rw-r--r-- 1 macports admin 6194 Mai 22 14:21 existing-perm-dir.log
-rw-r--r-- 1 macports admin 82 Mai 22 14:21 existing-perm-dir.trs
-rwxr-xr-x 1 macports admin 2882 Mai 22 13:02 existing-perm-race.sh
-rwxr-xr-x 1 macports admin 1736 Mai 22 13:02 file-perm-race.sh
-rwxr-xr-x 1 macports admin 1052 Jan 7 13:36 existing-perm-dir.sh
-rwxr-xr-x 1 macports admin 2007 Jan 7 13:36 fail-perm.sh
You can see that the untouched test shell scripts have an old date and two test shell scripts are younger, probably patched recently. Nevertheless 'make check' got stuck – I'll remove that test from Makefile for next try (when I'll also check whether two patched test shell scripts are reset).
--
Greetings
Pete
"Debugging? Klingons do not debug. Our software does not coddle the weak."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 14:02:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 78509 <at> debbugs.gnu.org (full text, mbox):
Sorry! I made a fault! I was still looking into the previously built and renamed tree. (Removed now.)
The two patch files are applied correctly to existing-perm-race.sh + file-perm-race.sh, and to Makefile.in. And I am being now in the proper tree…
--
Greetings
Pete
"Free markets would be a great idea, if markets were actually free."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 15:04:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 78509 <at> debbugs.gnu.org (full text, mbox):
I think I have a clue here:
last_component (name=0xbfffd607 "k") at lib/basename-lgpl.c:30
Run till exit from #0 last_component (name=0xbfffd607 "k") at lib/basename-lgpl.c:30
0x000042ac in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at src/mv.c:532
Value returned is $3 = 0xbfffd607 "k"
file_name_concat (dir=0xbfffd609 "out", base=0xbfffd607 "k", base_in_result=0xbfffd1b8) at lib/filenamecat.c:37
Run till exit from #0 file_name_concat (dir=0xbfffd609 "out", base=0xbfffd607 "k", base_in_result=0xbfffd1b8) at lib/filenamecat.c:37
0x000042bc in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at src/mv.c:532
Value returned is $4 = 0x4006c0 "out/k"
(gdb) step
strip_trailing_slashes (file=0x4006c4 "k") at lib/stripslash.c:33
Run till exit from #0 strip_trailing_slashes (file=0x4006c4 "k") at lib/stripslash.c:33
main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at src/mv.c:537
Value returned is $5 = false
do_move (source=0xbfffd607 "k", dest=0x4006c0 "out/k", dest_dirfd=7, dest_relname=0x4006c4 "k", x=0xbfffd21c) at src/mv.c:175
It looks as if erroneously file_name_concat() is invoked, maybe too early, which seems to be defined in lib/filenamecat.c:35? YES!
So I need to find out from where… And maybe why…
--
Greetings
Pete
Don't just do something, sit there.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 17:09:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 78509 <at> debbugs.gnu.org (full text, mbox):
Somewhere in mv.c it happens that variable target-directory gets loaded with the value "out\0". Although it should be "\0" or such.
Execution comes to
443 else if (target_directory)
and then
445 target_dirfd = target_directory_operand (target_directory, &sb);
I am missing the moment after declarations
325 char const *target_directory = nullptr;
326 bool no_target_directory = false;
when nullptr value changes to "out\0". I think GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007) could be instructed to watch over a variable – but have no idea how. Is this a watchpoint?
For today I am going rebuild coreutils 9.7 with -O0 and am going to check all tests, checking particularly how patched existing-perm-race.sh will perform.
--
Greetings
Pete
Specifications are for the weak and timid!
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 22:40:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 5/22/25 10:08, Peter Dyballa wrote:
> when nullptr value changes to "out\0". I think GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007) could be instructed to watch over a variable – but have no idea how. Is this a watchpoint?
Yes, it's the GDB command 'watch target_directory'.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 22:44:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 5/22/25 02:03, Peter Dyballa wrote:
> Trying to open on Macs non-existent "/proc/self/fd" could cause a failure state suggesting mv to fchdir into a file, "out"…
Shouldn't be a problem, as when /proc/self/fd doesn't work, coreutils is
supposed to fall back on older approaches (these have races but those
issues shouldn't apply here).
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 22 May 2025 22:48:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 5/22/25 10:08, Peter Dyballa wrote:
> Somewhere in mv.c it happens that variable target-directory gets loaded with the value "out\0".
Surely this occurs in src/mv.c's line "target_directory = d;". Please
investigate how mv got there.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Fri, 23 May 2025 08:05:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 78509 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Pádraig!
Yesterday coreutils did not build because of use of -O0 instead of -Os before. This morning I am using simply -O, and the tests stop at the test after existing-perm-dir.sh (last line in build log), which is existing-perm-race.sh.
coreutils-9.7/tests/cp has:
-rw-r--r-- 1 macports admin 6687 23. Mai 09:03 existing-perm-race.log
-rw-r--r-- 1 macports admin 6194 23. Mai 09:03 existing-perm-dir.log
-rw-r--r-- 1 macports admin 82 23. Mai 09:03 existing-perm-dir.trs
-rw-r--r-- 1 macports admin 6004 23. Mai 09:03 dir-vs-file.log
-rw-r--r-- 1 macports admin 82 23. Mai 09:03 dir-vs-file.trs
...
-rw-r--r-- 1 macports admin 7745 23. Mai 08:40 link-heap.log
-rw-r--r-- 1 macports admin 83 23. Mai 08:40 link-heap.trs
-rwxr-xr-x 1 macports admin 2882 23. Mai 08:21 existing-perm-race.sh
-rwxr-xr-x 1 macports admin 1736 23. Mai 08:21 file-perm-race.sh
-rwxr-xr-x 1 macports admin 1406 20. Jan 16:16 symlink-slash.sh
-rwxr-xr-x 1 macports admin 3477 7. Jan 18:31 cp-i.sh
-rwxr-xr-x 1 macports admin 1639 7. Jan 13:36 abuse.sh
which indicates that existing-perm-race.sh and file-perm-race.sh have been patched, as the compile log also indicates:
patch phase started at Fri May 23 08:21:43 CEST 2025
Executing org.macports.patch (coreutils-devel)
---> Applying patches to coreutils-devel
---> Applying patch-tests_cp_existing-perm-race.sh.diff
I observed an unpleasant behaviour of 'make check': When it's killed coreutils-9.7/tests/cp/existing-perm-race.log just vanishes. Is there a way to keep that "unfinished" log file, in order to find in it a possible clue for some misbehaviour?
The test log contains a complaint (?) about not knowing the local file systems – they are:
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/disk0s7 hfs 53515952 42970824 10289128 81% /
devfs devfs 1 1 0 100% /dev
fdesc fdesc 1 1 0 100% /dev
<volfs> volfs 512 512 0 100% /.vol
/dev/disk0s3 hfs 18852212 14069028 4783184 75% /Volumes/BSD-Linux
/dev/disk0s5 hfs 65678668 57482724 8195944 88% /Volumes/Leopard
/dev/disk0s9 hfs 17719744 15903256 1816488 90% /Volumes/Halde
See attached existing-perm-race.log and patched existing-perm-race.sh!
--
Greetings
Pete
"When you breathe, you inspire. When you do not breathe, you expire."
[existing-perm-race.log (application/octet-stream, attachment)]
[existing-perm-race.sh (application/octet-stream, attachment)]
[Message part 4 (text/plain, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Fri, 23 May 2025 08:19:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 78509 <at> debbugs.gnu.org (full text, mbox):
Paul,
I have a strange effect when building coreutils 9.7 with MacPorts. Yesterday I tried to build with -O0 – and it failed! This morning I repeated it – with same result:
/opt/local/bin/gcc-apple-4.2 -std=gnu99 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -fPIC -pipe -ggdb -O0 -arch ppc -MT src/libstdbuf_so-libstdbuf.o -MD -MP -MF src/.deps/libstdbuf_so-libstdbuf.Tpo -c -o src/libstdbuf_so-libstdbuf.o `test -f 'src/libstdbuf.c' || echo './'`src/libstdbuf.c
mv -f src/.deps/libstdbuf_so-libstdbuf.Tpo src/.deps/libstdbuf_so-libstdbuf.Po
/opt/local/bin/gcc-apple-4.2 -std=gnu99 -fPIC -pipe -ggdb -O0 -arch ppc -shared -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o src/libstdbuf.so src/libstdbuf_so-libstdbuf.o -lintl -Wl,-framework -Wl,CoreFoundation -Wl,-framework -Wl,CoreServices Undefined symbols:
"_fchownat", referenced from:
_chownat in libstdbuf_so-libstdbuf.o
_lchownat in libstdbuf_so-libstdbuf.o
"_fchmodat", referenced from:
_chmodat in libstdbuf_so-libstdbuf.o
_lchmodat in libstdbuf_so-libstdbuf.o
"_xreallocarray", referenced from:
_xnrealloc in libstdbuf_so-libstdbuf.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [src/libstdbuf.so] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_Volumes_BSD-Linux_MacPorts-Ports_sysutils_coreutils-devel/coreutils-devel/work/coreutils-9.7'
I saved config.log and config.status from a build with -O instead of standard -Os and shall check later with other builds. The functions listed above are not part of Mac OS X 10.4.11, Tiger (apropos tells: nothing appropriate).
--
Greetings
Pete
To most people solutions mean finding the answers. But to chemists solutions are things that are still all mixed up.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Fri, 23 May 2025 11:29:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 78509 <at> debbugs.gnu.org (full text, mbox):
When using Gdb I skip in mv.c's main() function over the first few calls and come to the while loop, line #344. It is entered and
378 target_directory = optarg;.
is – visited? The name "out" contains a "t" which is also listed in the list of command line options. After the while loop target_directory is still 0x0. It also "visits" line #386 because of "u". But this too does not seem to change anything…
But then the if at line
431 if (no_target_directory)
is reached. no_target_directory is false, so
443 else if (target_directory)
is reached. target_directory is still 0x0, the "nullptr", so we come to line
450 else
and then to an if on line
457 if (x.rename_errno != 0)
x.rename_errno is 17 and therefore != 0, so the if expression is true and its block entered:
458 {
459 int fd = target_directory_operand (lastfile, &sb);
460 if (target_dirfd_valid (fd))
461 {
462 x.rename_errno = -1;
463 target_dirfd = fd;
464 target_directory = lastfile;
465 n_files--;
466 }
467 else
468 {
...
484 }
485 }
Here x.rename_errno is (re)set to -1 although already != 0, and most importantly target_directory receives value "out". So from now on mv might be sure that something needs to be moved into a *directory* "out", and we come to
519 if (target_directory)
520 {
521 /* Initialize the hash table only if we'll need it.
522 The problem it is used to detect can arise only if there are
523 two or more files to move. */
524 if (2 <= n_files)
525 dest_info_init (&x);
526
527 ok = true;
528 for (int i = 0; i < n_files; ++i)
529 {
530 x.last_file = i + 1 == n_files;
531 char const *source = file[i];
532 char const *source_basename = last_component (source);
533 char *dest_relname;
534 char *dest = file_name_concat (target_directory, source_basename,
535 &dest_relname);
536 strip_trailing_slashes (dest_relname);
537 ok &= do_move (source, dest, target_dirfd, dest_relname, &x);
538 free (dest);
539 }
540 }
target_directory is "out" and therefore we enter the true block. n_files has been decremented on line #365, so dest_info_init() is not called and we enter the for loop to do our job…
The cause for faulty behaviour is the value of x.rename_errno. It receives its value from
450 else
451 {
452 char const *lastfile = file[n_files - 1];
453 if (n_files == 2 && !x.exchange)
454 x.rename_errno = (renameatu (AT_FDCWD, file[0], AT_FDCWD, lastfile,
455 RENAME_NOREPLACE)
456 ? errno : 0);
457 if (x.rename_errno != 0)
On line # 453 n_files is 2, and x.exchange is false, so we have if( true && true) and renameatu() is called, with:
renameatu (fd1=-3041965, src=0xbfffd607 "k", fd2=-3041965, dst=0xbfffd609 "out", flags=1) at lib/renameatu.c:257
254 #else /* !HAVE_RENAMEAT */
255
256 /* RENAME_NOREPLACE is the only flag currently supported. */
257 if (flags & ~RENAME_NOREPLACE)
258 return errno_fail (ENOTSUP);
259 return at_func2 (fd1, src, fd2, dst, flags ? rename_noreplace : rename);
260
261 #endif /* !HAVE_RENAMEAT */
Mac OS X 10.4, Tiger, does not have the renameat() system call, so not much is used from the GNUlib function.
The if clause on line #257 is false, so renameatu() returns, calling at_func2():
at_func2 (fd1=-3041965, file1=0xbfffd607 "k", fd2=-3041965, file2=0xbfffd609 "out", func=0x25270 <rename_noreplace>) at lib/at-func2.c:77
77 if ((fd1 == AT_FDCWD || IS_ABSOLUTE_FILE_NAME (file1))
78 && (fd2 == AT_FDCWD || IS_ABSOLUTE_FILE_NAME (file2)))
79 return func (file1, file2); /* Case 0-2, 4-6, 8-10. */
Here the if clause on lines #77/78 is true and func() is called:
rename_noreplace (src=0xbfffd607 "k", dst=0xbfffd609 "out") at lib/renameatu.c:55
39 #if HAVE_RENAMEAT
40 41 # include <stdlib.h>
42 # include <string.h>
43 44 # include "dirname.h"
45 # include "openat.h"
46 47 #else
48 # include "openat-priv.h"
49 50 static int
51 rename_noreplace (char const *src, char const *dst)
52 {
53 /* This has a race between the call to lstat and the call to rename. */
54 struct stat st;
55 return (lstat (dst, &st) == 0 || errno == EOVERFLOW ? errno_fail (EEXIST)
56 : errno == ENOENT ? rename (src, dst)
57 : -1);
58 }
59 #endif
Isn't calling rename_noreplace() already faulty? Shouldn't it be rename_and_do_replace_and/or_remove()?
The faulty behaviour starts here in mv.c:
454 x.rename_errno = (renameatu (AT_FDCWD, file[0], AT_FDCWD, lastfile,
455 RENAME_NOREPLACE)
RENAME_NOREPLACE should not be passed to the function here. Anyway, lib/renameatu.c is divided into two parts, one for systems with renameat() family of library functions and another one without them. And this part might behave differently and take the last parameter as a target directory.
I checked on my up-to-date Mac coreutils 9.7: mv -v k out just works! So I should start to debug here too to understand what produces the different behaviour – but first I need a working version of Gdb!
--
Greetings
Pete
Clovis' Consideration of an Atmospheric Anomaly:
The perversity of nature is nowhere better demonstrated than by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Fri, 23 May 2025 14:53:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 78509 <at> debbugs.gnu.org (full text, mbox):
Having finally managed to codesign Gdb!
On macOS Sonoma 14.7.4 (intel) mv starts as on PPC Tiger. It reaches lines #457 and #459, but "target_dirfd_valid (fd)" delivers here FALSE, deduced from the fact that line #478 gets executed with errno presumingly 20 (on line #480 I can print err, which gives this value). x.rename_errno from line #454 is 17, as on PPC Tiger.
457 if (x.rename_errno != 0)
458 {
459 int fd = target_directory_operand (lastfile, &sb);
460 if (target_dirfd_valid (fd))
461 {
462 x.rename_errno = -1;
463 target_dirfd = fd;
464 target_directory = lastfile;
465 n_files--;
466 }
467 else
468 {
469 /* The last operand LASTFILE cannot be opened as a directory.
470 If there are more than two operands, report an error.
471
472 Also, report an error if LASTFILE is known to be a directory
473 even though it could not be opened, which can happen if
474 opening failed with EACCES on a platform lacking O_PATH.
475 In this case use stat to test whether LASTFILE is a
476 directory, in case opening a non-directory with (O_SEARCH
477 | O_DIRECTORY) failed with EACCES not ENOTDIR. */
478 int err = errno;
479 if (2 < n_files
480 || (O_PATHSEARCH == O_SEARCH && err == EACCES
481 && (sb.st_mode != 0 || stat (lastfile, &sb) == 0)
482 && S_ISDIR (sb.st_mode)))
483 error (EXIT_FAILURE, err, _("target %s"), quoteaf (lastfile));
484 }
485 }
n_files is 2, EACCES is presumingly 13 (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/errno.h:101, /* Permission denied */) – the others I cannot tell (O_PATHSEARCH does not seem to exist, O_SEARCH is (O_EXEC | O_DIRECTORY)). The error() function is not executed and line #485 (no visible text output, cursor jumps over line #483) reached.
On line #519 target_directory is still 0x0, so
537 ok &= do_move (source, dest, target_dirfd, dest_relname, &x);
is reached and job done correctly:
pete 289 /\ ./ls -l k out
ls: Zugriff auf 'k' nicht möglich: No such file or directory
-rw-r--r-- 1 pete admin 0 23. Mai 15:38 out
Exit 2
Interestingly the output is so polyglot…
So presumingly it's not renameatu() but rather lib/targetdir.c:61:target_directory_operand (char const *file, struct stat *st) that is faulty…
OK, I'll try to continue a bit today!
--
Greetings
Pete
If the majority of cooking accidents happen in the kitchen, then why don't we just cook in other rooms?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Fri, 23 May 2025 16:12:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 23.05.2025 um 16:52 schrieb Peter Dyballa <Peter_Dyballa <at> Web.DE>:
>
> So presumingly it's not renameatu() but rather lib/targetdir.c:61:target_directory_operand (char const *file, struct stat *st) that is faulty…
In modern macOS target_directory_operand() returns -1, target_dirfd_valid(-1) evaluates to FALSE and so
463 target_dirfd = fd;
never happens, hence target_directory_operand() needs to be debugged – tomorrow!
--
Greetings
Pete
Real Time, adj.:
Here and now, as opposed to fake time, which only occurs there and then.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 07:45:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-23 04:27, Peter Dyballa wrote:
> 458 {
> 459 int fd = target_directory_operand (lastfile, &sb);
> 460 if (target_dirfd_valid (fd))
> 461 {
> 462 x.rename_errno = -1;
> 463 target_dirfd = fd;
> 464 target_directory = lastfile;
> 465 n_files--;
> 466 }
> 467 else
> 468 {
> ...
> 484 }
> 485 }
>
> Here x.rename_errno is (re)set to -1 although already != 0,
If this is "mv k out" where "out" is not a directory, then you're
closing in on the bug. target_directory_operand is supposed to fail
(i.e., return a value for which target_dirfd_valid is false) if LASTFILE
is not a directory, and LASTFILE is "out" here.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 07:52:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 09:44 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> On 2025-05-23 04:27, Peter Dyballa wrote:
>> 458 {
>> 459 int fd = target_directory_operand (lastfile, &sb);
>> 460 if (target_dirfd_valid (fd))
>> 461 {
>> 462 x.rename_errno = -1;
>> 463 target_dirfd = fd;
>> 464 target_directory = lastfile;
>> 465 n_files--;
>> 466 }
>> 467 else
>> 468 {
>> ...
>> 484 }
>> 485 }
>> Here x.rename_errno is (re)set to -1 although already != 0,
>
> If this is "mv k out" where "out" is not a directory, then you're closing in on the bug. target_directory_operand is supposed to fail (i.e., return a value for which target_dirfd_valid is false) if LASTFILE is not a directory, and LASTFILE is "out" here.
You are saying that the GNUlib function target_directory_operand() is known to fail when the target of cp or mv is a file? So I do not need to debug further?
And yes, I am debugging in coreutils-9.7/src with Gdb "./mv k out" where k and out were created by "./touch k out".
--
Greetings
Pete
If all else fails read the instructions.
- Donald Knuth
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 08:25:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 78509 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2025-05-23 01:17, Peter Dyballa wrote:
> Undefined symbols:
> "_fchownat", referenced from:
> _chownat in libstdbuf_so-libstdbuf.o
> _lchownat in libstdbuf_so-libstdbuf.o
> "_fchmodat", referenced from:
> _chmodat in libstdbuf_so-libstdbuf.o
> _lchmodat in libstdbuf_so-libstdbuf.o
> "_xreallocarray", referenced from:
> _xnrealloc in libstdbuf_so-libstdbuf.o
What's the definition of _GL_INLINE and _GL_EXTERN_INLINE?
Does the attached patch work around the problem?
[stdbuf.diff (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 08:38:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-24 00:51, Peter Dyballa wrote:
> You are saying that the GNUlib function target_directory_operand() is known to fail when the target of cp or mv is a file? So I do not need to debug further?
No, I'm saying that target_directory_operand is supposed to fail if it's
given the name of a regular file. (It should succeed only on
directories.) You're reporting that it succeeded, which means there's
something wrong here.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 09:53:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 10:24 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> On 2025-05-23 01:17, Peter Dyballa wrote:
>> Undefined symbols:
>> "_fchownat", referenced from:
>> _chownat in libstdbuf_so-libstdbuf.o
>> _lchownat in libstdbuf_so-libstdbuf.o
>> "_fchmodat", referenced from:
>> _chmodat in libstdbuf_so-libstdbuf.o
>> _lchmodat in libstdbuf_so-libstdbuf.o
>> "_xreallocarray", referenced from:
>> _xnrealloc in libstdbuf_so-libstdbuf.o
>
> What's the definition of _GL_INLINE and _GL_EXTERN_INLINE?
I performed
/opt/local/bin/gcc-apple-4.2 -std=gnu99 -I. -I./lib -Ilib -I./lib -Isrc -I./src -I/opt/local/include -fPIC -pipe -ggdb -O0 -arch ppc -E -dD -o src/libstdbuf.cpp src/libstdbuf.c
and then ggrep'ped for the two in src/libstdbuf.cpp:
#define _GL_INLINE _GL_UNUSED static
#define _GL_EXTERN_INLINE _GL_UNUSED static
#define _GL_UNUSED _GL_ATTRIBUTE_MAYBE_UNUSED
#define _GL_ATTRIBUTE_MAYBE_UNUSED _GL_ATTRIBUTE_UNUSED
#define _GL_ATTRIBUTE_UNUSED __attribute__ ((__unused__))
tiger pete 238 /\ ggrep ' _GL_' src/libstdbuf.cpp | ggrep _INLINE | sort
#define ATTRIBUTE_ALWAYS_INLINE _GL_ATTRIBUTE_ALWAYS_INLINE
#define CHMODAT_INLINE _GL_INLINE
#define CHOWNAT_INLINE _GL_INLINE
#define SAME_INODE_INLINE _GL_INLINE
#define XALLOC_INLINE _GL_INLINE
#define _GL_ATTRIBUTE_ALWAYS_INLINE __attribute__ ((__always_inline__))
#define _GL_EXTERN_INLINE _GL_UNUSED static
#define _GL_EXTERN_INLINE_STDHEADER_BUG #define _GL_GETPAGESIZE_INLINE _GL_INLINE
#define _GL_INLINE _GL_UNUSED static
#define _GL_INLINE_HEADER_BEGIN #define _GL_INLINE_HEADER_END #define _GL_REALLOC_INLINE _GL_INLINE
#define _GL_STDLIB_INLINE _GL_INLINE
#define _GL_TIMESPEC_INLINE _GL_INLINE
#define _GL_UNISTD_INLINE _GL_INLINE
tiger pete 239 /\ ggrep ' _GL_' src/libstdbuf.cpp | ggrep _UNUSED | sort
#define MAYBE_UNUSED _GL_ATTRIBUTE_MAYBE_UNUSED
#define _GL_ATTRIBUTE_MAYBE_UNUSED _GL_ATTRIBUTE_UNUSED
#define _GL_ATTRIBUTE_UNUSED __attribute__ ((__unused__))
#define _GL_EXTERN_INLINE _GL_UNUSED static
#define _GL_INLINE _GL_UNUSED static
#define _GL_UNUSED _GL_ATTRIBUTE_MAYBE_UNUSED
#define _GL_UNUSED_LABEL _GL_ATTRIBUTE_UNUSED
#define _UNUSED_PARAMETER_ _GL_ATTRIBUTE_MAYBE_UNUSED
--
Greetings
Pete
Atheism is a non prophet organisation.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 10:52:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 10:24 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> Does the attached patch work around the problem?
Yes, it does! It also build fine with -Os.
--
Greetings
Pete
"Indentation?! I will show you how to indent when I indent your skull!"
– Unknown Klingon typist.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 18:46:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 10:36 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> On 2025-05-24 00:51, Peter Dyballa wrote:
>> You are saying that the GNUlib function target_directory_operand() is known to fail when the target of cp or mv is a file? So I do not need to debug further?
>
> No, I'm saying that target_directory_operand is supposed to fail if it's given the name of a regular file. (It should succeed only on directories.) You're reporting that it succeeded, which means there's something wrong here.
This function in lib/targetdir.c, target_directory_operand(), seems to work OK:
63 if (must_be_working_directory (file))
evaluates to false
72 if (!O_DIRECTORY)
evaluates to false – and we come to:
88 if (try_to_open)
89 {
90 fd = open (file, O_PATHSEARCH | O_DIRECTORY);
91
92 /* On platforms lacking O_PATH, using O_SEARCH | O_DIRECTORY to
93 open an overly-protected non-directory can fail with either
94 EACCES or ENOTDIR. Prefer ENOTDIR as it makes for better
95 diagnostics. */
96 if (O_PATHSEARCH == O_SEARCH && fd < 0 && errno == EACCES)
97 errno = (((O_DIRECTORY ? stat (file, st) : stat_result) == 0
98 && !S_ISDIR (st->st_mode))
99 ? ENOTDIR : EACCES);
100 }
open() on line #90 returns 7, so the if on line #96 evaluates to false and we're on line
117 return fd - (AT_FDCWD == -1 && fd < 0);
AT_FDCWD is replaced by a large negative value (found by pre-processing the source) and fd is larger than 0: how can an integer minus a logical expression, that evaluates to FALSE, be evaluated and returned? (Because TRUE and FALSE are some integer values…)
Anyway, back in mv.c fd is still 7. And we come to function target_dirfd_valid() in lib/targetdir.h (no openat in Tiger):
29 /* Return a file descriptor open to FILE, for use in openat.
30 As an optimization, return AT_FDCWD if FILE must be the working directory.
31 As a side effect, possibly set *ST to the file's status.
32 Fail and set errno if FILE is not a directory.
33 On failure return -2 if AT_FDCWD is -1, -1 otherwise. */
34 extern int target_directory_operand (char const *file, struct stat *st);
35
36 /* Return true if FD represents success for target_directory_operand. */
37 TARGETDIR_INLINE _GL_ATTRIBUTE_PURE bool
38 target_dirfd_valid (int fd)
39 {
40 return fd != -1 - (AT_FDCWD == -1);
41 }
In pre-processed output of src/mv.c is this line:
14590 return fd != -1 - ((-3041965) == -1);
This is TRUE minus FALSE, isn't it? It must be true – because Gdb executes this block in src/mv.c:
461 {
462 x.rename_errno = -1;
463 target_dirfd = fd;
464 target_directory = lastfile;
465 n_files--;
466 }
And the target file has turned into a target directory…
Is the old way of checking with S_IFDIR and stat() or fstat() too out-fashioned? Why is the value of O_DIRECTORY used for complicated different things when it can be used directly? Besides, the decisive function, target_dirfd_valid(), seems to check only if the file descriptor is valid. I cannot see that it makes a distinction whether fd is that of a(n ordinary) file or a directory.
--
Greetings
Pete
No one is patriotic about taxes.
– George Orwell, Orwell Diaries 1938-1942, (1940-08-09)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 19:34:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-24 11:45, Peter Dyballa wrote:
> This function in lib/targetdir.c, target_directory_operand(), seems to work OK:
>
> 63 if (must_be_working_directory (file))
>
> evaluates to false
>
> 72 if (!O_DIRECTORY)
>
> evaluates to false – and we come to:
>
> 88 if (try_to_open)
> 89 {
> 90 fd = open (file, O_PATHSEARCH | O_DIRECTORY);
> 91
> 92 /* On platforms lacking O_PATH, using O_SEARCH | O_DIRECTORY to
> 93 open an overly-protected non-directory can fail with either
> 94 EACCES or ENOTDIR. Prefer ENOTDIR as it makes for better
> 95 diagnostics. */
> 96 if (O_PATHSEARCH == O_SEARCH && fd < 0 && errno == EACCES)
> 97 errno = (((O_DIRECTORY ? stat (file, st) : stat_result) == 0
> 98 && !S_ISDIR (st->st_mode))
> 99 ? ENOTDIR : EACCES);
> 100 }
>
> open() on line #90 returns 7
That's wrong. O_DIRECTORY means that open should fail when FILE is not a
directory". In this case the file is "out" which is a regular file not a
directory. Perhaps macOS is ignoring the O_DIRECTORY flag?
Can you verify that a simple program like the following triggers this
macOS bug? If so, we might be able to work around it. You may need to
munge this program a bit to get it to compile and illustrate the bug on
macOS.
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#ifndef O_SEARCH
# define O_SEARCH O_RDONLY
#endif
int
main ()
{
int fd = open ("out", O_WRONLY | O_CREAT, 0666);
if (fd < 0)
return perror ("create"), 1;
close (fd);
fd = open ("out", O_SEARCH | O_DIRECTORY);
if (fd < 0 && errno == ENOTDIR)
return 0;
if (fd < 0)
return perror ("open"), 1;
fprintf (stderr, "O_DIRECTORY incorrectly succeeded!\n");
return 1;
}
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 19:58:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 24.05.2025 um 21:33 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> Can you verify that a simple program like the following triggers this macOS bug? If so, we might be able to work around it.
The output is: "O_DIRECTORY incorrectly succeeded!"
> You may need to munge this program a bit to get it to compile and illustrate the bug on macOS.
What does "to munge" mean? No printed dictionary or online translator is able to tell me what it is meaning in German. I first saw it over 40 years ago. Then a utility of ispell had this name…
O_DIRECTORY is #define'd in /usr/include/sys/fcntl.h:
139 #ifndef _POSIX_C_SOURCE
140 #define O_DIRECTORY 0x100000
141 #endif
--
Greetings
Pete
To drink without thirst and to make love all the time, madam, it is only these which distinguish us from the other beasts.
– Beaumarchais
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Sat, 24 May 2025 20:05:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-24 03:51, Peter Dyballa wrote:
> Yes, it does! It also build fine with -Os.
Thanks, I installed that patch into Gnulib and it should appear in the
next Coreutils release.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 28 May 2025 20:00:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 2025-05-24 12:57, Peter Dyballa wrote:
> The output is: "O_DIRECTORY incorrectly succeeded!"
Thanks for checking. I installed fixes to Autoconf, Gnulib and Coreutils
to try to address the two bug reports <https://bugs.gnu.org/78562> and
<https://bugs.gnu.org/78562>.
The fixes are so complicated that patching is not likely to be easy, so
I generated a complete coreutils distribution tarball with the changes.
Please try this tarball. You can get it temporarily from:
https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
... or you can generate the tarball yourself from Savannah git master
coreutils.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 28 May 2025 20:17:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On 28/05/2025 20:58, Paul Eggert wrote:
> On 2025-05-24 12:57, Peter Dyballa wrote:
>> The output is: "O_DIRECTORY incorrectly succeeded!"
>
> Thanks for checking. I installed fixes to Autoconf, Gnulib and Coreutils
> to try to address the two bug reports <https://bugs.gnu.org/78562> and
> <https://bugs.gnu.org/78562>.
>
> The fixes are so complicated that patching is not likely to be easy, so
> I generated a complete coreutils distribution tarball with the changes.
> Please try this tarball. You can get it temporarily from:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
>
> ... or you can generate the tarball yourself from Savannah git master
> coreutils.
Really nice work on this.
It's great this is all now encapsulated in gnulib,
and code can now assume contemporary systems in this regard.
thanks!
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Wed, 28 May 2025 20:20:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 28.05.2025 um 21:58 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> You can get it temporarily from:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
I fetched it! I'll try tomorrow on both Macs.
I'll also check with diffutils, https://debbugs.gnu.org/db/77/77840.html. Is it possible, and advised, to use the Gnulib sources from coreutils-9.7.39-c8d75 in diffutils 3.12? The new version of coreutils could cure many of its test failures, but diff itself has problems too – that might come from Gnulib…
Anyway, I hope I'll see more tomorrow!
--
Greetings
Pete
The human brain operates at only 10% of its capacity. The rest is overhead for the operating system.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 29 May 2025 11:06:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 28.05.2025 um 21:58 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
Solves the problem: ./mv -v k out succeeds: k vanishes and out is still a file! (Now testing.)
--
Greetings
Pete
No matter which way you ride, it's uphill and against the wind.
– First Law of Bicycling
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 29 May 2025 15:58:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 78509 <at> debbugs.gnu.org (full text, mbox):
> Am 28.05.2025 um 21:58 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> https://web.cs.ucla.edu/~eggert/coreutils-9.7.39-c8d75.tar.gz
This is the result of testing:
========================================================
GNU coreutils 9.7.39-c8d75: ./tests/test-suite.log
========================================================
# TOTAL: 659
# PASS: 461
# SKIP: 194
# XFAIL: 0
# FAIL: 4
# XPASS: 0
# ERROR: 0
System information (uname -a): Darwin 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh
FAILures come from missing tests/env/env-S, tests/sort/sort-discrim, tests/timeout/timeout-group, and tests/cp/attr-existing. The latter could be SKIPped because Tiger can only handle some attribute basics:
+ returns_ 1 cp -a --attributes-only sym1 file2
cp: cannot create symbolic link 'file2': File exists
+ cmp file2 file2.exp
+ cp -a --remove-destination --attributes-only sym1 file2
cp: preserving times for 'file2': Function not implemented
I also performed some commands with mv and cp manually that failed before. Now they do work.
Testing diffutils 3.12 does not work here – because the function SIGSEGV_FOR_ALL_SIGNALS() does not exist, so no build. But I think the coreutils are now OK!
--
Greetings
Pete
If men could get pregnant, abortion would be a sacrament.
– Florynce Kennedy
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Thu, 29 May 2025 16:13:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Peter Dyballa <Peter_Dyballa <at> Web.DE>:
bug acknowledged by developer.
(Thu, 29 May 2025 16:13:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 78509-done <at> debbugs.gnu.org (full text, mbox):
On 2025-05-29 08:57, Peter Dyballa wrote:
> I think the coreutils are now OK!
Thanks for checking; closing the two coreutils bug reports.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#78509; Package
coreutils.
(Thu, 05 Jun 2025 10:18:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 78509 <at> debbugs.gnu.org (full text, mbox):
On PPC Mac OS X 10.5.8, Leopard, Coreutils-9.5 already worked OK, coreutils-9.7.39-c8d75.tar.gz does the same, and tests show only one failure in env-S with __CF_USER_TEXT_ENCODING, as on Tiger, PPC Mac OS X 10.4.11.
--
Greetings
Pete
The future will be much better tomorrow.
– George W. Bush
This bug report was last modified 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.