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 >>> 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@gmx.fr > 18 place Jean Moulin - 38000 Grenoble APsudo - 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