On 2025-09-13 10:36, Steffen Nurpmeso wrote:
Paul Eggert wrote in
|that cp fails because fchmodat2 fails. So it sounds like we have been
|barking up the wrong tree by worrying about the chown-related syscalls,
|and that we should instead worry about chmod-related syscalls.
Seems like that.
On further looking at your trace in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79433#23> it seems that I
was mistaken. Even though the fchmodat2 syscall fails with ENOSYS, it
appears that the glibc fchmodat library function then calls openat with
O_NOFOLLOW|O_PATH and then calls fstatat+AT_EMPTY_PATH, determines that
"c" is a symlink, and then returns -1 with errno=ENOTSUP.
But then I'm lost. If b is a symlink, I don't see why 'cp -a b c' would
ever call fchmodat. The coreutils 9.7 source code says that fopr
symlinks copy_internal should call symlinkat via force_symlinkat
(copy.c:3117), then fchownat via lchownat (copy.c:3152), then utimensat
(copy.c:3227), but it should never call fchmodat.
Could you investigate why coreutils 9.7 cp is not behaving the way the
source code says it should? You can use a debugger, or insert print
statements, to figure out why in this particular case it is going awry.
Lets get the chmod issue figured out first. We can worry about the chown
issue later; one thing at a time.
