Paul Eggert wrote in
<[email protected]>:
|On 2025-09-17 09:46, Steffen Nurpmeso wrote:
|> (Just wondering, the final cp(1) should work for all
|> configurable cases if config succeeds;
|
|That sounds pretty ambitious! The main goal here is merely for coreutils
|to work on practical platforms.
I think there are / have been filesystems with a time resolution
smaller than one second.
...
|> #?0|kent:tmp$ /bin/cp -a xb xc
|> cp: failed to preserve ownership for xc: Operation not supported
|
|That's not preserving permissions; it's preserving ownership. It's a
|different system call, with quite different semantics.
The GNU autoconf result of coreutils / cp results in a code
path that does not work the way it should. That much is plain,
and that i reported. I am not looking into GNU autoconf aka the
conclusions of GNU coreutils and the resulting coreutils / gnulib
/ GNU libc module / overlay / patchwork fusion which results.
Also since i went several times for you in the past and have been
dismissed drastically, just like again this time.
I also disagree with "practical platforms" given that the
effective log difference seems to be (from a diff(1) glance)
+#define CHOWN_CHANGE_TIME_BUG 1
+#define MKNOD_FIFO_BUG 1
The latter seems to come from
configure:65539: checking whether mknod can create fifo without root
privileges
...
configure:65580: $? = 99
...
| /* Indeterminate for super-user, assume no. Why are you running
| configure as root, anyway? */
| if (geteuid () == ROOT_UID) return 99;
| if (mknod ("conftest.fifo", S_IFIFO | 0600, 0)) return 2;
| ;
| return 0;
| }
configure:65601: result: no
Not a bug.
All in all the two above, plus some getgroups() difference should not result in
a disfunctional cp(1) i would think.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
