GNU bug report logs - #55023
Issue with CP empty folder after y2038 on 32-bits Kernel

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#55023: closed (Issue with CP empty folder after y2038 on
 32-bits Kernel)
Date: Wed, 27 Apr 2022 16:43:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 27 Apr 2022 17:42:47 +0100
with message-id <3c7a9382-6d04-3fdf-685d-c5c66f91f024 <at> draigBrady.com>
and subject line Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel
has caused the debbugs.gnu.org bug report #55023,
regarding Issue with CP empty folder after y2038 on 32-bits Kernel
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
55023: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55023
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Arnaud Panaïotis <arnaud.panaiotis <at> gmx.fr>
To: bug-coreutils <at> gnu.org
Subject: Re: Issue with CP empty folder after y2038 on 32-bits Kernel
Date: Tue, 19 Apr 2022 09:47:25 +0200

[Message part 3 (text/plain, inline)]

Hello,

I did not received any feedback from this request right now. Have you
made any progress on this subject ?

Please let me know the progress for this, or contact me for additional
information if needed.

I'd like to have a ticket link to follow the advancement of this issue
(if possible). I'm available to test a patch if you are able to provide
me one.

Best regards,

On 01/04/2022 15:55, Arnaud Panaïotis wrote:
>
> Hello,
>
> I'm working for a client to generate embedded 32-bits Linux Kernel
> working after y2038 issue.
>
> I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC
> 11.2.0, Binutils 2.37 and CFLAGS  -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64  -D_TIME_BITS=64
>
> The Kernel pass y2038 but I found an issue with cp:
> After analysis, the error occurs when trying to move an empty folder
> without all user mode rights.
>
> Here how to reproduce:
>
> # mkdir -p test/test1 folder
> # chmod u-w test/test1
> # date -s "2040-04-02"
> # cp -a test/* folder/
> cp: setting permissions for 'folder/test1' : Value too large for defined data type
>
> Note: The folder is copied before the error occurs. The copy works
> fine before y2038.
>
>
> The issue comes from coreutils-9.0/src/cp.c
>
> Line 512 : if (lchmod (dir, stats.st_mode | S_IRWXU) != 0)
>
> FYI I had a previous issue while calling lstat function from
> <sys/stat.h> which is included in lib/lchmod.c. I used /usr/bin/stat
> as a workaround.
>
>
> Keep me in touch if you need more information.
>
> --
>
> *Arnaud PANAÏOTIS* | Lead Developer Freelance
> +33 6 34 82 12 62 | arnaud.panaiotis <at> gmx.fr <mailto:Arnaud Panaïotis
> <arnaud.panaiotis <at> gmx.fr>>
>
> 18 place Jean Moulin - 38000 Grenoble - France
> APsudo - www.panaiotis.fr <https://www.panaiotis.fr>
--

*Arnaud PANAÏOTIS* | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis <at> gmx.fr <mailto:Arnaud Panaïotis
<arnaud.panaiotis <at> gmx.fr>>

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr <https://www.panaiotis.fr>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

[Message part 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Pádraig Brady <P <at> draigBrady.com>
To: Adhemerval Zanella <adhemerval.zanella <at> linaro.org>,
 Arnaud Panaïotis <arnaud.panaiotis <at> gmx.fr>,
 55023-done <at> debbugs.gnu.org
Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits
 Kernel
Date: Wed, 27 Apr 2022 17:42:47 +0100

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.

Previous Next

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