On 27/04/2022 13:42, Pádraig Brady wrote:
> 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.
>
It is now fixed on master, 2.35, and 2.34 branches.
