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: Arnaud Panaïotis <arnaud.panaiotis <at> gmx.fr>
To: Pádraig Brady <P <at> draigBrady.com>, 55023 <at> debbugs.gnu.org
Subject: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel
Date: Tue, 19 Apr 2022 17:01:35 +0200

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

On 19/04/2022 16:00, Pádraig Brady wrote:
> On 19/04/2022 08:47, Arnaud Panaïotis wrote:
>> 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.
>
> The original mail seems to not have hit the lists, sorry.
>
> The error suggests that the fstatat() done within lchmod()
> is using a 32 bit time_t component of the stat structure.
> Your kernel is new enough to support the 64 bit equivalent,
> but you don't mention glibc. Can you ensure you're using
> at least glibc 2.34, which added support for the 64 bit variants.
>
> coreutils is configured by default to enable use
> of the 64 bit variants where available, and you've confirmed
> this as you say both -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 are
> defined.
>
> An strace of the cp command would be useful to confirm the problematic
> syscall.
>
> thanks,
> Pádraig

Hello,

Thanks for the quick answer.

My glibc is 2.34-9 (2.34-9-g9acab0bba6a5a57323b1f94bf95b21618a9e5aa4).

Strace attached.

Except for the stat.h, I encountered no issue with Kernel, mysql, my
application...

I indeed suspect stat.h to use a 32 bits time_t somewhere.

Regards,

--

*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 2 (text/html, inline)]

[strace-cp2038.log (text/plain, attachment)]

Previous Next

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