GNU bug report logs - #79433
9.7: cp(1): lchownat(2/3) fallback bogus?

Previous Next

Full log

Message #32 received at 79433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Steffen Nurpmeso <steffen <at> sdaoden.eu>
Cc: 79433 <at> debbugs.gnu.org
Subject: Re: bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?
Date: Mon, 15 Sep 2025 10:44:28 -0700

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.