Marking this as done in the coreutils bug tracker,
now that this is being tracked in glibc.
thank you!
On 27/04/2022 13:46, Adhemerval Zanella wrote:
On 21/04/2022 14:36, Pádraig Brady wrote:
That suggests the kernel (statx) returns fine,
but glibc's fstatat64 is returning the EOVERFLOW.
It seems to be a glibc missing support indeed. The coreutils issues indicates
that lchmodat failed somehow:
if (lchmodat (dst_dirfd, dst_relname, dst_mode | S_IRWXU) != 0)
{
error (0, errno, _("setting permissions for %s"),
quoteaf (dst_name));
goto un_backup;
}
And lchmodat is a gnulib wrapper for fchmodat:
CHMODAT_INLINE int
lchmodat (int fd, char const *file, mode_t mode)
{
return fchmodat (fd, file, mode, AT_SYMLINK_NOFOLLOW);
}
And since Linux fchmodat syscall does not provide a 'flag' argument (to
handle AT_SYMLINK_NOFOLLOW), glibc emulates it through opening a procfs file
descriptor, issuing fstatat to check if it is link (since some kernels and
filesystem it returns in inconsistent results), and then issue chmod.
However, the glibc internal fstat does not use the 64-bit version, which
then results in EOVERFLOW.
I have opened https://sourceware.org/bugzilla/show_bug.cgi?id=29097 and I will
fix it upstream and backport to 2.34 and 2.35.
