bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel


From: Pádraig Brady
Subject: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel
Date: Wed, 27 Apr 2022 17:42:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]