From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 07:16:59 2022 Received: (at submit) by debbugs.gnu.org; 19 Apr 2022 11:16:59 +0000 Received: from localhost ([127.0.0.1]:41801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nglqt-0001Sr-6b for submit@debbugs.gnu.org; Tue, 19 Apr 2022 07:16:59 -0400 Received: from lists.gnu.org ([209.51.188.17]:46546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngiaA-0002IG-SU for submit@debbugs.gnu.org; Tue, 19 Apr 2022 03:47:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngiaA-0000TK-Dg for bug-coreutils@gnu.org; Tue, 19 Apr 2022 03:47:30 -0400 Received: from mout.gmx.net ([212.227.17.20]:58721) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ngia8-0003fG-7D for bug-coreutils@gnu.org; Tue, 19 Apr 2022 03:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650354445; bh=ktcUDuN46U142LbikcdzEs66B8G5pf2Yja4ASs98uRg=; h=X-UI-Sender-Class:Date:Subject:From:To:References:In-Reply-To; b=AUPqCJu4M4lgQ3r8Q9adjAxxZaAkqSmORVqyPn2IHbPU5s9dNfMdojomOtubegAZ4 xOjVga+4k2vi/9uuuEubLcBo4OhPr2AqFCXpK2g2dHgLR6cX6P2fbnMDN2176lCgNF DfptTAo9D3TI+7YEIdEMtF4mKja1v156xvCK4eAM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [100.120.35.85] ([51.158.21.218]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MeCtj-1oEgUE0J9D-00bING for ; Tue, 19 Apr 2022 09:47:25 +0200 Content-Type: multipart/alternative; boundary="------------PqApDscBwORJ72FPZsffrn9i" Message-ID: <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> Date: Tue, 19 Apr 2022 09:47:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US From: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= To: bug-coreutils@gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> In-Reply-To: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> X-Antivirus: Avast (VPS 220418-6, 18/4/2022), Outbound message X-Antivirus-Status: Clean X-Provags-ID: V03:K1:XHeeX9odi4km9VK0hKbsg0Ip9c+j8Kzn0ICCuKlKzg9/EE31BQi wQi57FDxmYSYc1zFLw08adN3zGjdDMoE6NM8qh7vejlf4yibJE4a/d9ViaMoNNkS64gsqNG WSVCSDjWeRVBmkaYast5V49x0DK8ehCS+In6frdratLzzqvj3jtdi66qH0yG50laAIsUTXF dRGVSzu6uxypo9Gena/Vw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:aPR3a+XNo54=:mNrGUa6E/uC+hj/LlMwX0m VEZgzaI25sl2ZrUO2bzsTGfiVwIA/Hp95eI85PW76D5wuK/Noez8V4zNgo1nxHp/gKGeP81Ur C3nucq3SUek2eyKfUengA4rshTUgZ7uvdtZccFJRw0dKDFwJBLOczaVl95HfpKl4lo/o2T14t kQJWWbATJdW5NfsV5QREUgsID2hChWCwuTLbRnasKRn1AGNbhK4z/0mmP/WLSPELSrXMwJxxa GOW418dauVK/CbsjrecwEGlTr3YJKiImAoSdIHLu1D4yLwXfS5gqKxibVkjMvmMkGjiydVjLb VXMu1mm3N/71pH59SYrwsATCgBtBSPqW+HZBBxhF7HYTA4qOJagU+z9DftJpY/shLqwGIqWTO Pquzno+H+B8hj7w6BydmbxkG4/5c2qoCUzeBGnrYzk0+ZuMcQqklj3ee3zUdhU/um4tgCh3Xy yoPF3aIsu83LbvXolhsy1JPVP/HyNBbN4xIaE3o/AJayj/Nod78V1vLt4kgcuuTLvs+b5q0BS M+7aSdfa1HRRE5KZjjWdDRWEIaBjbyUOv7/Qgg8Di+8Rt/EL7weaiicE/rzosfkd9Ew2S59F8 9uzTUIgxFDqoqgZuSD6Y2aCb/Di2q0T/Ymhi9YtzTVQ9LirKhbnZV7Fn6M/YpLWSKHOLIsc7J glPG0Bl4STDJNz0lCG5M1wWTjcUu5QalZ0w+3rRtpbuRPlGdFSTjIeGVksS89lclXs8X07jVT D/4N91V0H0vKVrMk9BoGZyuCDQA1Pd3rzB8IJGn3OIwPiXPlms71e3TrvWzYguPFonP/tcXRt 0mi0BjA89sDatiJObLCKO7lxlZQBokaarYRkzTI2qzEyggJn+JrcUUf9BkGNzDs+29fLhCJeD e3Ohh7Jcls1m2hfkWLdUHLXbShEGRu75yhlMP/dAiuXr3NX4sHc4AqYha1yj+sJMlflU0nACt uvBVVm+UHUi8DrsWClOKUL+L/p/8xrAqZav/P8qVOKF0TQbKIC3Y3HZ3kcewfQM7G73/O873x 1eSy6MIQrnrr4gem9cARPWRpzhCEfZjCUIs6wr+42A1MRuSA4du4R6aU635/WpCLyWWUf6VEO jLfjsyRqcKuVAc= Received-SPF: pass client-ip=212.227.17.20; envelope-from=arnaud.panaiotis@gmx.fr; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 19 Apr 2022 07:16:57 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) This is a multi-part message in MIME format. --------------PqApDscBwORJ72FPZsffrn9i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=C3=AFotis 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=C2=A0 -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64 > > 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) !=3D 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. > > -- > > *Arnaud PANA=C3=8FOTIS* | Lead Developer Freelance > +33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr > > > 18 place Jean Moulin - 38000 Grenoble - France > APsudo - www.panaiotis.fr =2D- *Arnaud PANA=C3=8FOTIS* | Lead Developer Freelance +33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr > 18 place Jean Moulin - 38000 Grenoble APsudo - www.panaiotis.fr =2D- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. https://www.avast.com/antivirus --------------PqApDscBwORJ72FPZsffrn9i Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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=C3=AFo= tis 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=C2=A0 -D_LARGEFILE_SOURCE=C2= =A0 -D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64

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 fo=
r 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) !=3D 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=C3=8FOTIS | Lead Developer Freelance

        +33 6 34 82 12 62 | arnaud=
.panaiotis@gmx.fr

        

        18 place Jean Moulin - 38000 Grenoble - France

        APsudo - www.panaiotis.fr
--

Arnaud PANA=C3=8FOTIS | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr

18 place Jean Moulin - 38000 Grenoble
APsudo - www.= panaiotis.fr


3D"Avast

L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 = v=C3=A9rifi=C3=A9e par le logiciel antivirus Avast.
www.avast.com


--------------PqApDscBwORJ72FPZsffrn9i-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 10:00:35 2022 Received: (at 55023) by debbugs.gnu.org; 19 Apr 2022 14:00:35 +0000 Received: from localhost ([127.0.0.1]:43831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngoPD-0006IJ-59 for submit@debbugs.gnu.org; Tue, 19 Apr 2022 10:00:35 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:45040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngoPB-0006I3-6a for 55023@debbugs.gnu.org; Tue, 19 Apr 2022 10:00:33 -0400 Received: by mail-wr1-f50.google.com with SMTP id b19so22544576wrh.11 for <55023@debbugs.gnu.org>; Tue, 19 Apr 2022 07:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=q7lq3MKlhABDg3M3EJYyma+jNbMmCpT4grsFbUM9qFM=; b=U1xvNm5+/yTzZP46sSn8AQPjmlNXUMhepuu+MZjOj40g/xrqtrCsrUbYyS6GhnXD90 HeXESjXw4unfLc0dsR8hAwQl/ZkWImO0Pu9m944Gg6weku8oDHKh4XHwoO2xkKxlhrxV i3RyDpUJ8L3UALiWoVVzBWOgUBk38mW2LrCf8WN2ZqnSVzqhN9bylm5IMY5mnEP98OhQ VV59N5uQ0I9bRnOEsyTMDW1Hmcwsv5J0Uc3sAjoo0qqCOHCYKkx2t8jlqgndnmrLYIYz uktF7T18qr/hW3XHVMPNRskkw/lgdcWGXeE7yhjbJkBwYnicdI59t800g5hxJ/ouzYLy S4Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=q7lq3MKlhABDg3M3EJYyma+jNbMmCpT4grsFbUM9qFM=; b=mehACIaCBt2bFWtGFHlsGplTynUXxfk/30Nlpmro3OMv+qhOwmHxxhQ0vOWu5s6bB3 Cu5s9FdTp3yArn3eBK8PL9TL1G3SNbXczQqmzHopMqFJrHjFa1nU1Ptugqb/B+u+FOvd H2kWx33xLpC8PJT72cpKleViUuY4vO6JkLv7JH07KlXLwP2PLZ5HhpEnq+PvR3lH8cmo 9EMkk+s6CvMU0womOs5NLESNkLEEwLc1MnblvnBurxoaSlAAt94J4kqC21wKaK4JH0L9 f6Te82nGxJ8igJa9h88F7dqfo1OffgUh+Jn6CdBB41EQXcY+SL4UAJjOaoRdsakGlJJP lJWg== X-Gm-Message-State: AOAM532V2BTiMlSg+WLLpwI9rdZBKRZdR+kTok9a1thgw/4HmkSR/SvD n8mD36+aHXB/zP7pXHs41jI= X-Google-Smtp-Source: ABdhPJwc33vWDKVKw3eb1/czTYUubG90Q8Pv4f7FlvNBKyA6kI2+rmsVqgAvj0z6lPUMuCA4kACH9A== X-Received: by 2002:a05:6000:1d86:b0:20a:91e6:c2d0 with SMTP id bk6-20020a0560001d8600b0020a91e6c2d0mr8541978wrb.530.1650376827008; Tue, 19 Apr 2022 07:00:27 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id n68-20020a1c2747000000b0038e6b4d5395sm17184091wmn.16.2022.04.19.07.00.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Apr 2022 07:00:26 -0700 (PDT) Message-ID: <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> Date: Tue, 19 Apr 2022 15:00:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 19 11:01:45 2022 Received: (at 55023) by debbugs.gnu.org; 19 Apr 2022 15:01:45 +0000 Received: from localhost ([127.0.0.1]:43902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngpMO-0007oS-EM for submit@debbugs.gnu.org; Tue, 19 Apr 2022 11:01:45 -0400 Received: from mout.gmx.net ([212.227.17.22]:57989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ngpML-0007oE-V1 for 55023@debbugs.gnu.org; Tue, 19 Apr 2022 11:01:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650380495; bh=sUTx04N+JFwcGljhI7ez+MHubLj+8wKg7tBSr+mBvC8=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=isWUl2CtByx9vAgb2XwduI+YaNIFopOmaQ+1gMIL8jnTTeHNiXaaRX+jchSzwpDY/ akscAi3M9FIS/GmABQzB1eAFg+gGOhqBkxSEr3NINXhQnAC1lbS6jSJ3MOPhB/STdQ 0Shepzewyai4LYPIktB8mqWjc1UFp5qTvgNU+ejg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [100.120.35.85] ([51.158.21.218]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1M8QS8-1ncRe31nQ8-004SNT; Tue, 19 Apr 2022 17:01:35 +0200 Content-Type: multipart/mixed; boundary="------------COWUHwWy3000Wt0WE43oJ62E" Message-ID: <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> Date: Tue, 19 Apr 2022 17:01:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> From: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= In-Reply-To: <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> X-Antivirus: Avast (VPS 220419-6, 19/4/2022), Outbound message X-Antivirus-Status: Clean X-Provags-ID: V03:K1:TS1sP9x4rRv/H4jVDK3Nwe2rgAQT9ng3f2SigFMBidrvK2VeMvu 4rwDwpvobzFEKw3knPICZh5pj2nFwww8uBauixRCstskHf/i0cl46mJ2lWru3A3xUGTpFby 12VfuSWPzneotgigbpuHnerebQY8dPi67nY5O9lcdnxW2ObxoEFyGcHpCiB6+Hay/hi1oG2 mt8E2fEpPL5Vt33Yvspqg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:B9qRRxgB2Dk=:jky6Z48yOWN4QT/CxaIX6W n0UX9HwL13j8Seu62oAhPX2AM+j5PaX+t0k2bSYG9F+zOAW48hV74/tf6BqEc3RuWoYMkEsV+ vmYVnSN0g/SkYzNpx5xD4A3NYu6VmLtiIziWGUTUQqImM8tXDYSi3P3elKDlYRDh7CU3zAgAF LBJe/5srV85AF0RG/Q5JeQumCZKtZppNOM9W32TjtKvDkyLAsbSqyEx7EFQIfP+RUeo79YbR9 E8xfM0h99NrWeIImH4gc8zJQLXsIqJ5osrmh3cqAm8Uz74v9+iZ5mIrValH9rKk2cMEKlvdmq dSgkHCoHb4NlxFu4yNwEEj9lcHTwM6fZ7thqLLhuJM1whPpBVoY9ZLUK2EknxBEWcrNiufjgR FzsMW3jw31CY+OL2t4LOmVkIbR++gFX6smR9plfgsIilmQdDCRjGlLwZPbVCwdNFBwboolwMX zMxikVeqtJ096t8ixQpgFq2kFp5LijhbQ2nHeVg3CvwwwTCR4sk33wHZo3MNCD3uSqjeG+8Rt G8c7CrgEmFbc15D7Tz8nSrVZTuY1CxFW5XRQWHB2c9cDBYh0pVMtVMSaX7L1oS3jMptj3e/rP wX9CrGdjqDrhdHi6barndc7GdIxyA8oi/yyOumt7b6FONbNTybmKFQjGDijPEMbhW38xFXiEU u/l/YHRkGSiSkTBxr5tCQ97IxOtoMwPqBmkb0Z1LJPUAI5cJt6Rt1PVp6SA+Mj8VxZBSQm0kG iG5fUuiLJbElWQanW/4R2eZ60YSiOdkj2txpkvOMMsS4ud5X9R3gkpwTOC12PIWnqw8t5CXa+ 9crW+Vqxcp6u9flQ3WuAfQnb7sfxhZKYV9FRmIXcSeeE/mzpEOpHL/3ghLhhDi2aD/ZCn2pkq l05mmFyvg2bW6f5KCF/qxTllKuc/n/aJY0lg0C5GiPyIFNPih4EezBnIjv+dsmNPHku3g8J9n oLGYGepi00/CyOgOIwWkDbx85CtU8xTGLssd++NBAoqNkwUhGmtFdM5TqHqWo5DEcgbADBvlf YTMO255a8W1sNxw62FpckbRn55fQrGb0/1oban0kjtRLIRr03yMuO/EV4VSrO6ni+awaUU85K IRULWNu7mYzQ4A= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------COWUHwWy3000Wt0WE43oJ62E Content-Type: multipart/alternative; boundary="------------fyKMQ4qaAYJBWT6dq1z2Z4JK" --------------fyKMQ4qaAYJBWT6dq1z2Z4JK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 19/04/2022 16:00, P=C3=A1draig Brady wrote: > On 19/04/2022 08:47, Arnaud Pana=C3=AFotis 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=C3=AFotis 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=C2=A0 -D_LARGEFILE_SOURCE >>> -D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64 >>> >>> 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) !=3D 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=3D64 and -D_TIME_BITS=3D64 are > defined. > > An strace of the cp command would be useful to confirm the problematic > syscall. > > thanks, > P=C3=A1draig 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, =2D- *Arnaud PANA=C3=8FOTIS* | Lead Developer Freelance +33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr > 18 place Jean Moulin - 38000 Grenoble APsudo - www.panaiotis.fr =2D- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. https://www.avast.com/antivirus --------------fyKMQ4qaAYJBWT6dq1z2Z4JK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19/04/2022 16:00, P=C3=A1draig Brady wrote:
On 19/04/2022 08:47, Arnaud Pana=C3=AFotis 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=C3=AFotis 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=C2=A0 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64

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) !=3D 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=3D64 and -D_TIME_BITS=3D64 are defined.

An strace of the cp command would be useful to confirm the problematic syscall.

thanks,
P=C3=A1draig

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=C3=8FOTIS | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr

18 place Jean Moulin - 38000 Grenoble
APsudo - www.= panaiotis.fr


3D"Avast

L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 = v=C3=A9rifi=C3=A9e par le logiciel antivirus Avast.
www.avast.com


--------------fyKMQ4qaAYJBWT6dq1z2Z4JK-- --------------COWUHwWy3000Wt0WE43oJ62E Content-Type: text/plain; charset=UTF-8; name="strace-cp2038.log" Content-Disposition: attachment; filename="strace-cp2038.log" Content-Transfer-Encoding: base64 ZXhlY3ZlKCIvYmluL2NwIiwgWyJjcCIsICItYSIsICJ0ZXN0L3Rlc3QxIiwgImZvbGRlciJd LCAweGJmZjhjNWM0IC8qIDE0IHZhcnMgKi8pID0gMApicmsoTlVMTCkgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPSAweDUxNTAwMAptbWFwMihOVUxMLCA4MTkyLCBQUk9UX1JF QUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsIDApID0gMHhi N2ZjMTAwMAphY2Nlc3MoIi9ldGMvbGQuc28ucHJlbG9hZCIsIFJfT0spICAgICAgPSAtMSBF Tk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgInRs cy9pNjg2L3NzZTIvbGliYWNsLnNvLjEiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VY RUMpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRf RkRDV0QsICJ0bHMvaTY4Ni9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9f Q0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5h dChBVF9GRENXRCwgInRscy9zc2UyL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJ TEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkK b3BlbmF0KEFUX0ZEQ1dELCAidGxzL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJ TEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkK b3BlbmF0KEFUX0ZEQ1dELCAiaTY4Ni9zc2UyL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19M QVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiaTY4Ni9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9f TEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnkpCm9wZW5hdChBVF9GRENXRCwgInNzZTIvbGliYWNsLnNvLjEiLCBPX1JET05MWXxP X0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICJsaWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFS R0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnkpCm9wZW5hdChBVF9GRENXRCwgIi9vcHQvYXBwcy9jdXJyZW50L3Vzci9saWIvdGxzL2k2 ODYvc3NlMi9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykg PSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0YXR4KEFUX0ZEQ1dE LCAiL29wdC9hcHBzL2N1cnJlbnQvdXNyL2xpYi90bHMvaTY4Ni9zc2UyIiwgQVRfU1RBVFhf U1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZh YmU2MDgpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQo QVRfRkRDV0QsICIvb3B0L2FwcHMvY3VycmVudC91c3IvbGliL3Rscy9pNjg2L2xpYmFjbC5z by4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgoQVRfRkRDV0QsICIvb3B0L2FwcHMvY3Vy cmVudC91c3IvbGliL3Rscy9pNjg2IiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FV VE9NT1VOVCwgU1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvb3B0L2FwcHMv Y3VycmVudC91c3IvbGliL3Rscy9zc2UyL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJH RUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eSkKc3RhdHgoQVRfRkRDV0QsICIvb3B0L2FwcHMvY3VycmVudC91c3IvbGliL3Rscy9zc2Uy IiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFTSUNf U1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvb3B0L2FwcHMvY3VycmVudC91c3IvbGliL3Rscy9s aWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9F TlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0YXR4KEFUX0ZEQ1dELCAiL29wdC9h cHBzL2N1cnJlbnQvdXNyL2xpYi90bHMiLCBBVF9TVEFUWF9TWU5DX0FTX1NUQVR8QVRfTk9f QVVUT01PVU5ULCBTVEFUWF9CQVNJQ19TVEFUUywgMHhiZmFiZTYwOCkgPSAtMSBFTk9FTlQg KE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgIi9vcHQvYXBw cy9jdXJyZW50L3Vzci9saWIvaTY4Ni9zc2UyL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19M QVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeSkKc3RhdHgoQVRfRkRDV0QsICIvb3B0L2FwcHMvY3VycmVudC91c3IvbGliL2k2ODYv c3NlMiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRPTU9VTlQsIFNUQVRYX0JB U0lDX1NUQVRTLCAweGJmYWJlNjA4KSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRp cmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiL29wdC9hcHBzL2N1cnJlbnQvdXNyL2xpYi9p Njg2L2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0x IEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgoQVRfRkRDV0QsICIv b3B0L2FwcHMvY3VycmVudC91c3IvbGliL2k2ODYiLCBBVF9TVEFUWF9TWU5DX0FTX1NUQVR8 QVRfTk9fQVVUT01PVU5ULCBTVEFUWF9CQVNJQ19TVEFUUywgMHhiZmFiZTYwOCkgPSAtMSBF Tk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgIi9v cHQvYXBwcy9jdXJyZW50L3Vzci9saWIvc3NlMi9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9f TEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnkpCnN0YXR4KEFUX0ZEQ1dELCAiL29wdC9hcHBzL2N1cnJlbnQvdXNyL2xpYi9zc2Uy IiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFTSUNf U1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvb3B0L2FwcHMvY3VycmVudC91c3IvbGliL2xpYmFj bC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAo Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgoQVRfRkRDV0QsICIvb3B0L2FwcHMv Y3VycmVudC91c3IvbGliIiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VO VCwgU1RBVFhfQkFTSUNfU1RBVFMsIHtzdHhfbWFzaz1TVEFUWF9CQVNJQ19TVEFUU3xTVEFU WF9NTlRfSUQsIHN0eF9hdHRyaWJ1dGVzPTAsIHN0eF9tb2RlPVNfSUZESVJ8MDc1NSwgc3R4 X3NpemU9MTAyNCwgLi4ufSkgPSAwCm9wZW5hdChBVF9GRENXRCwgIi9ldGMvbGQuc28uY2Fj aGUiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvbGliL3Rscy9pNjg2 L3NzZTIvbGliYWNsLnNvLjEiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0g LTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpzdGF0eChBVF9GRENXRCwg Ii9saWIvdGxzL2k2ODYvc3NlMiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRP TU9VTlQsIFNUQVRYX0JBU0lDX1NUQVRTLCAweGJmYWJlNjA4KSA9IC0xIEVOT0VOVCAoTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiL2xpYi90bHMvaTY4 Ni9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBF Tk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0YXR4KEFUX0ZEQ1dELCAiL2xp Yi90bHMvaTY4NiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRPTU9VTlQsIFNU QVRYX0JBU0lDX1NUQVRTLCAweGJmYWJlNjA4KSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiL2xpYi90bHMvc3NlMi9saWJhY2wu c28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0YXR4KEFUX0ZEQ1dELCAiL2xpYi90bHMvc3Nl MiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRPTU9VTlQsIFNUQVRYX0JBU0lD X1NUQVRTLCAweGJmYWJlNjA4KSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiL2xpYi90bHMvbGliYWNsLnNvLjEiLCBPX1JET05M WXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5KQpzdGF0eChBVF9GRENXRCwgIi9saWIvdGxzIiwgQVRfU1RBVFhfU1lOQ19B U19TVEFUfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZhYmU2MDgp ID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRD V0QsICIvbGliL2k2ODYvc3NlMi9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxF fE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0 YXR4KEFUX0ZEQ1dELCAiL2xpYi9pNjg2L3NzZTIiLCBBVF9TVEFUWF9TWU5DX0FTX1NUQVR8 QVRfTk9fQVVUT01PVU5ULCBTVEFUWF9CQVNJQ19TVEFUUywgMHhiZmFiZTYwOCkgPSAtMSBF Tk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgIi9s aWIvaTY4Ni9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykg PSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0YXR4KEFUX0ZEQ1dE LCAiL2xpYi9pNjg2IiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VOVCwg U1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvbGliL3NzZTIvbGliYWNsLnNv LjEiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpzdGF0eChBVF9GRENXRCwgIi9saWIvc3NlMiIsIEFU X1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRPTU9VTlQsIFNUQVRYX0JBU0lDX1NUQVRT LCAweGJmYWJlNjA4KSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkK b3BlbmF0KEFUX0ZEQ1dELCAiL2xpYi9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VG SUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkp CnN0YXR4KEFUX0ZEQ1dELCAiL2xpYiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19B VVRPTU9VTlQsIFNUQVRYX0JBU0lDX1NUQVRTLCB7c3R4X21hc2s9U1RBVFhfQkFTSUNfU1RB VFN8U1RBVFhfTU5UX0lELCBzdHhfYXR0cmlidXRlcz0wLCBzdHhfbW9kZT1TX0lGRElSfDA3 NTUsIHN0eF9zaXplPTQwOTYsIC4uLn0pID0gMApvcGVuYXQoQVRfRkRDV0QsICIvdXNyL2xp Yi90bHMvaTY4Ni9zc2UyL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19D TE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgo QVRfRkRDV0QsICIvdXNyL2xpYi90bHMvaTY4Ni9zc2UyIiwgQVRfU1RBVFhfU1lOQ19BU19T VEFUfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZhYmU2MDgpID0g LTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0Qs ICIvdXNyL2xpYi90bHMvaTY4Ni9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxF fE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0 YXR4KEFUX0ZEQ1dELCAiL3Vzci9saWIvdGxzL2k2ODYiLCBBVF9TVEFUWF9TWU5DX0FTX1NU QVR8QVRfTk9fQVVUT01PVU5ULCBTVEFUWF9CQVNJQ19TVEFUUywgMHhiZmFiZTYwOCkgPSAt MSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwg Ii91c3IvbGliL3Rscy9zc2UyL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8 T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3Rh dHgoQVRfRkRDV0QsICIvdXNyL2xpYi90bHMvc3NlMiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RB VHxBVF9OT19BVVRPTU9VTlQsIFNUQVRYX0JBU0lDX1NUQVRTLCAweGJmYWJlNjA4KSA9IC0x IEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAi L3Vzci9saWIvdGxzL2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9F WEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgoQVRf RkRDV0QsICIvdXNyL2xpYi90bHMiLCBBVF9TVEFUWF9TWU5DX0FTX1NUQVR8QVRfTk9fQVVU T01PVU5ULCBTVEFUWF9CQVNJQ19TVEFUUywgMHhiZmFiZTYwOCkgPSAtMSBFTk9FTlQgKE5v IHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgIi91c3IvbGliL2k2 ODYvc3NlMi9saWJhY2wuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykg PSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCnN0YXR4KEFUX0ZEQ1dE LCAiL3Vzci9saWIvaTY4Ni9zc2UyIiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FV VE9NT1VOVCwgU1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChO byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvdXNyL2xpYi9p Njg2L2xpYmFjbC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0x IEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgoQVRfRkRDV0QsICIv dXNyL2xpYi9pNjg2IiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VOVCwg U1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvdXNyL2xpYi9zc2UyL2xpYmFj bC5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAo Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKc3RhdHgoQVRfRkRDV0QsICIvdXNyL2xpYi9z c2UyIiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFT SUNfU1RBVFMsIDB4YmZhYmU2MDgpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvdXNyL2xpYi9saWJhY2wuc28uMSIsIE9fUkRP TkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAzCnJlYWQoMywgIlwxNzdFTEZcMVwxXDFc MFwwXDBcMFwwXDBcMFwwXDBcM1wwXDNcMFwxXDBcMFwwXDIyMCNcMFwwMDA0XDBcMFwwIi4u LiwgNTEyKSA9IDUxMgpwcmVhZDY0KDMsICJcNFwwXDBcMFwzMFwwXDBcMFw1XDBcMFwwR05V XDBcMVwwXDFcMzAwXDRcMFwwXDBcdFwwXDBcMFwyXDBcMVwzMDAiLi4uLCA0MCwgMjgzODAp ID0gNDAKc3RhdHgoMywgIiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRPTU9V TlR8QVRfRU1QVFlfUEFUSCwgU1RBVFhfQkFTSUNfU1RBVFMsIHtzdHhfbWFzaz1TVEFUWF9C QVNJQ19TVEFUU3xTVEFUWF9NTlRfSUQsIHN0eF9hdHRyaWJ1dGVzPTAsIHN0eF9tb2RlPVNf SUZSRUd8MDc1NSwgc3R4X3NpemU9MzQwMjQsIC4uLn0pID0gMAptbWFwMihOVUxMLCAzNjg5 MiwgUFJPVF9SRUFELCBNQVBfUFJJVkFURXxNQVBfREVOWVdSSVRFLCAzLCAwKSA9IDB4Yjdm YjcwMDAKbXByb3RlY3QoMHhiN2ZiOTAwMCwgMjQ1NzYsIFBST1RfTk9ORSkgID0gMAptbWFw MigweGI3ZmI5MDAwLCAxNjM4NCwgUFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8 TUFQX0ZJWEVEfE1BUF9ERU5ZV1JJVEUsIDMsIDB4MjAwMCkgPSAweGI3ZmI5MDAwCm1tYXAy KDB4YjdmYmQwMDAsIDQwOTYsIFBST1RfUkVBRCwgTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1B UF9ERU5ZV1JJVEUsIDMsIDB4NjAwMCkgPSAweGI3ZmJkMDAwCm1tYXAyKDB4YjdmYmYwMDAs IDgxOTIsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQ X0RFTllXUklURSwgMywgMHg3MDAwKSA9IDB4YjdmYmYwMDAKY2xvc2UoMykgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID0gMApvcGVuYXQoQVRfRkRDV0QsICJ0bHMvaTY4Ni9z c2UyL2xpYmF0dHIuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAt MSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwg InRscy9pNjg2L2xpYmF0dHIuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhF QykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9G RENXRCwgInRscy9zc2UyL2xpYmF0dHIuc28uMSIsIE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9f Q0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5h dChBVF9GRENXRCwgInRscy9saWJhdHRyLnNvLjEiLCBPX1JET05MWXxPX0xBUkdFRklMRXxP X0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVu YXQoQVRfRkRDV0QsICJpNjg2L3NzZTIvbGliYXR0ci5zby4xIiwgT19SRE9OTFl8T19MQVJH RUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eSkKb3BlbmF0KEFUX0ZEQ1dELCAiaTY4Ni9saWJhdHRyLnNvLjEiLCBPX1JET05MWXxPX0xB UkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5KQpvcGVuYXQoQVRfRkRDV0QsICJzc2UyL2xpYmF0dHIuc28uMSIsIE9fUkRPTkxZfE9f TEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnkpCm9wZW5hdChBVF9GRENXRCwgImxpYmF0dHIuc28uMSIsIE9fUkRPTkxZfE9fTEFS R0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnkpCm9wZW5hdChBVF9GRENXRCwgIi9vcHQvYXBwcy9jdXJyZW50L3Vzci9saWIvbGliYXR0 ci5zby4xIiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAo Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiL2xpYi9saWJh dHRyLnNvLjEiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5U IChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICIvdXNyL2xp Yi9saWJhdHRyLnNvLjEiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gMwpy ZWFkKDMsICJcMTc3RUxGXDFcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMFwzXDBcMVwwXDBc MFwyNjBcMjJcMFwwMDA0XDBcMFwwIi4uLiwgNTEyKSA9IDUxMgpwcmVhZDY0KDMsICJcNFww XDBcMFwzMFwwXDBcMFw1XDBcMFwwR05VXDBcMVwwXDFcMzAwXDRcMFwwXDBcdFwwXDBcMFwy XDBcMVwzMDAiLi4uLCA0MCwgMTQxMDgpID0gNDAKc3RhdHgoMywgIiIsIEFUX1NUQVRYX1NZ TkNfQVNfU1RBVHxBVF9OT19BVVRPTU9VTlR8QVRfRU1QVFlfUEFUSCwgU1RBVFhfQkFTSUNf U1RBVFMsIHtzdHhfbWFzaz1TVEFUWF9CQVNJQ19TVEFUU3xTVEFUWF9NTlRfSUQsIHN0eF9h dHRyaWJ1dGVzPTAsIHN0eF9tb2RlPVNfSUZSRUd8MDc1NSwgc3R4X3NpemU9MTc2NDAsIC4u Ln0pID0gMAptbWFwMihOVUxMLCAyMDQ5NiwgUFJPVF9SRUFELCBNQVBfUFJJVkFURXxNQVBf REVOWVdSSVRFLCAzLCAwKSA9IDB4YjdmYjEwMDAKbW1hcDIoMHhiN2ZiMjAwMCwgODE5Miwg UFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9ERU5ZV1JJ VEUsIDMsIDB4MTAwMCkgPSAweGI3ZmIyMDAwCm1tYXAyKDB4YjdmYjQwMDAsIDQwOTYsIFBS T1RfUkVBRCwgTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9ERU5ZV1JJVEUsIDMsIDB4MzAw MCkgPSAweGI3ZmI0MDAwCm1tYXAyKDB4YjdmYjUwMDAsIDgxOTIsIFBST1RfUkVBRHxQUk9U X1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX0RFTllXUklURSwgMywgMHgzMDAw KSA9IDB4YjdmYjUwMDAKY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID0gMApvcGVuYXQoQVRfRkRDV0QsICJ0bHMvaTY4Ni9zc2UyL2xpYmMuc28uNiIsIE9fUkRP TkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgInRscy9pNjg2L2xpYmMuc28uNiIsIE9f UkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgInRscy9zc2UyL2xpYmMuc28uNiIs IE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgInRscy9saWJjLnNvLjYiLCBP X1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBzdWNoIGZp bGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICJpNjg2L3NzZTIvbGliYy5zby42 IiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVOT0VOVCAoTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiaTY4Ni9saWJjLnNvLjYi LCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gLTEgRU5PRU5UIChObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5KQpvcGVuYXQoQVRfRkRDV0QsICJzc2UyL2xpYmMuc28uNiIs IE9fUkRPTkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgImxpYmMuc28uNiIsIE9fUkRP TkxZfE9fTEFSR0VGSUxFfE9fQ0xPRVhFQykgPSAtMSBFTk9FTlQgKE5vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnkpCm9wZW5hdChBVF9GRENXRCwgIi9vcHQvYXBwcy9jdXJyZW50L3Vzci9s aWIvbGliYy5zby42IiwgT19SRE9OTFl8T19MQVJHRUZJTEV8T19DTE9FWEVDKSA9IC0xIEVO T0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkKb3BlbmF0KEFUX0ZEQ1dELCAiL2xp Yi9saWJjLnNvLjYiLCBPX1JET05MWXxPX0xBUkdFRklMRXxPX0NMT0VYRUMpID0gMwpyZWFk KDMsICJcMTc3RUxGXDFcMVwxXDNcMFwwXDBcMFwwXDBcMFwwXDNcMFwzXDBcMVwwXDBcMFwy NDBcMjVcMlwwMDA0XDBcMFwwIi4uLiwgNTEyKSA9IDUxMgpwcmVhZDY0KDMsICJcNFwwXDBc MFwyMFwwXDBcMFwxXDBcMFwwR05VXDBcMFwwXDBcMFw1XDBcMFwwXG5cMFwwXDBcMFwwXDBc MCIuLi4sIDg0LCA0NjgpID0gODQKc3RhdHgoMywgIiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RB VHxBVF9OT19BVVRPTU9VTlR8QVRfRU1QVFlfUEFUSCwgU1RBVFhfQkFTSUNfU1RBVFMsIHtz dHhfbWFzaz1TVEFUWF9CQVNJQ19TVEFUU3xTVEFUWF9NTlRfSUQsIHN0eF9hdHRyaWJ1dGVz PTAsIHN0eF9tb2RlPVNfSUZSRUd8MDc1NSwgc3R4X3NpemU9MjE3OTgwOCwgLi4ufSkgPSAw Cm1tYXAyKE5VTEwsIDIyMTc3ODgsIFBST1RfUkVBRCwgTUFQX1BSSVZBVEV8TUFQX0RFTllX UklURSwgMywgMCkgPSAweGI3ZDkzMDAwCm1tYXAyKDB4YjdkYjMwMDAsIDE0ODI3NTIsIFBS T1RfUkVBRHxQUk9UX0VYRUMsIE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfREVOWVdSSVRF LCAzLCAweDIwMDAwKSA9IDB4YjdkYjMwMDAKbW1hcDIoMHhiN2YxZDAwMCwgNTUyOTYwLCBQ Uk9UX1JFQUQsIE1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfREVOWVdSSVRFLCAzLCAweDE4 YTAwMCkgPSAweGI3ZjFkMDAwCm1tYXAyKDB4YjdmYTQwMDAsIDEyMjg4LCBQUk9UX1JFQUR8 UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9ERU5ZV1JJVEUsIDMsIDB4 MjEwMDAwKSA9IDB4YjdmYTQwMDAKbW1hcDIoMHhiN2ZhNzAwMCwgMzg3MTYsIFBST1RfUkVB RHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX0FOT05ZTU9VUywgLTEs IDApID0gMHhiN2ZhNzAwMApjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPSAwCnNldF90aHJlYWRfYXJlYSh7ZW50cnlfbnVtYmVyPS0xLCBiYXNlX2FkZHI9MHhi N2ZjMjljMCwgbGltaXQ9MHgwZmZmZmYsIHNlZ18zMmJpdD0xLCBjb250ZW50cz0wLCByZWFk X2V4ZWNfb25seT0wLCBsaW1pdF9pbl9wYWdlcz0xLCBzZWdfbm90X3ByZXNlbnQ9MCwgdXNl YWJsZT0xfSkgPSAwIChlbnRyeV9udW1iZXI9NikKc2V0X3RpZF9hZGRyZXNzKDB4YjdmYzJh MjgpICAgICAgICAgICAgID0gMzcxOQpzZXRfcm9idXN0X2xpc3QoMHhiN2ZjMmEzMCwgMTIp ICAgICAgICAgPSAwCm1wcm90ZWN0KDB4YjdmYTQwMDAsIDgxOTIsIFBST1RfUkVBRCkgICA9 IDAKbXByb3RlY3QoMHhiN2ZiNTAwMCwgNDA5NiwgUFJPVF9SRUFEKSAgID0gMAptcHJvdGVj dCgweGI3ZmJmMDAwLCA0MDk2LCBQUk9UX1JFQUQpICAgPSAwCm1wcm90ZWN0KDB4NTEzMDAw LCA0MDk2LCBQUk9UX1JFQUQpICAgICA9IDAKbXByb3RlY3QoMHhiN2ZmOTAwMCwgODE5Miwg UFJPVF9SRUFEKSAgID0gMAp1Z2V0cmxpbWl0KFJMSU1JVF9TVEFDSywge3JsaW1fY3VyPTgx OTIqMTAyNCwgcmxpbV9tYXg9UkxJTV9JTkZJTklUWX0pID0gMApnZXRldWlkMzIoKSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPSAwCmdldHJhbmRvbSgiXHhmNlx4NDRceDlhXHhk ZiIsIDQsIEdSTkRfTk9OQkxPQ0spID0gNApicmsoTlVMTCkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPSAweDUxNTAwMApicmsoMHg1MzYwMDApICAgICAgICAgICAgICAgICAg ICAgICAgICAgPSAweDUzNjAwMApicmsoMHg1MzcwMDApICAgICAgICAgICAgICAgICAgICAg ICAgICAgPSAweDUzNzAwMApzdGF0eChBVF9GRENXRCwgImZvbGRlciIsIEFUX1NUQVRYX1NZ TkNfQVNfU1RBVHxBVF9OT19BVVRPTU9VTlQsIFNUQVRYX0JBU0lDX1NUQVRTLCB7c3R4X21h c2s9U1RBVFhfQkFTSUNfU1RBVFN8U1RBVFhfTU5UX0lELCBzdHhfYXR0cmlidXRlcz0wLCBz dHhfbW9kZT1TX0lGRElSfDA3NTUsIHN0eF9zaXplPTQwOTYsIC4uLn0pID0gMApzdGF0eChB VF9GRENXRCwgInRlc3QvdGVzdDEiLCBBVF9TVEFUWF9TWU5DX0FTX1NUQVR8QVRfU1lNTElO S19OT0ZPTExPV3xBVF9OT19BVVRPTU9VTlQsIFNUQVRYX0JBU0lDX1NUQVRTLCB7c3R4X21h c2s9U1RBVFhfQkFTSUNfU1RBVFN8U1RBVFhfTU5UX0lELCBzdHhfYXR0cmlidXRlcz0wLCBz dHhfbW9kZT1TX0lGRElSfDA1NTUsIHN0eF9zaXplPTQwOTYsIC4uLn0pID0gMApzdGF0eChB VF9GRENXRCwgImZvbGRlci90ZXN0MSIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9TWU1M SU5LX05PRk9MTE9XfEFUX05PX0FVVE9NT1VOVCwgU1RBVFhfQkFTSUNfU1RBVFMsIDB4YmZh YmViZjApID0gLTEgRU5PRU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQpta2Rpcigi Zm9sZGVyL3Rlc3QxIiwgMDUwMCkgICAgICAgICAgICAgPSAwCnN0YXR4KEFUX0ZEQ1dELCAi Zm9sZGVyL3Rlc3QxIiwgQVRfU1RBVFhfU1lOQ19BU19TVEFUfEFUX1NZTUxJTktfTk9GT0xM T1d8QVRfTk9fQVVUT01PVU5ULCBTVEFUWF9CQVNJQ19TVEFUUywge3N0eF9tYXNrPVNUQVRY X0JBU0lDX1NUQVRTfFNUQVRYX01OVF9JRCwgc3R4X2F0dHJpYnV0ZXM9MCwgc3R4X21vZGU9 U19JRkRJUnwwNTAwLCBzdHhfc2l6ZT00MDk2LCAuLi59KSA9IDAKb3BlbmF0KEFUX0ZEQ1dE LCAiZm9sZGVyL3Rlc3QxIiwgT19SRE9OTFl8T19OT0ZPTExPV3xPX0NMT0VYRUN8T19QQVRI KSA9IDMKc3RhdHgoMywgIiIsIEFUX1NUQVRYX1NZTkNfQVNfU1RBVHxBVF9OT19BVVRPTU9V TlR8QVRfRU1QVFlfUEFUSCwgU1RBVFhfQkFTSUNfU1RBVFMsIHtzdHhfbWFzaz1TVEFUWF9C QVNJQ19TVEFUU3xTVEFUWF9NTlRfSUQsIHN0eF9hdHRyaWJ1dGVzPTAsIHN0eF9tb2RlPVNf SUZESVJ8MDUwMCwgc3R4X3NpemU9NDA5NiwgLi4ufSkgPSAwCmNsb3NlKDMpICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA9IDAKd3JpdGUoMiwgImNwOiAiLCA0KSAgICAgICAg ICAgICAgICAgICAgID0gNAp3cml0ZSgyLCAic2V0dGluZyBwZXJtaXNzaW9ucyBmb3IgJ2Zv bGRlci8iLi4uLCAzOCkgPSAzOAp3cml0ZSgyLCAiOiBWYWx1ZSB0b28gbGFyZ2UgZm9yIGRl ZmluZWQgZGEiLi4uLCAzOSkgPSAzOQp3cml0ZSgyLCAiXG4iLCAxKSAgICAgICAgICAgICAg ICAgICAgICAgPSAxCl9sbHNlZWsoMCwgMCwgMHhiZmFiZjIwMCwgU0VFS19DVVIpICAgICA9 IC0xIEVTUElQRSAoSWxsZWdhbCBzZWVrKQpjbG9zZSgwKSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPSAwCmNsb3NlKDEpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA9IDAKY2xvc2UoMikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMApleGl0 X2dyb3VwKDEpICAgICAgICAgICAgICAgICAgICAgICAgICAgPSA/CisrKyBleGl0ZWQgd2l0 aCAxICsrKwo= --------------COWUHwWy3000Wt0WE43oJ62E-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 21 08:36:22 2022 Received: (at 55023) by debbugs.gnu.org; 21 Apr 2022 12:36:22 +0000 Received: from localhost ([127.0.0.1]:48625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhW2o-0007ay-6I for submit@debbugs.gnu.org; Thu, 21 Apr 2022 08:36:22 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:34351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhW2m-0007ah-Jq for 55023@debbugs.gnu.org; Thu, 21 Apr 2022 08:36:21 -0400 Received: by mail-wr1-f51.google.com with SMTP id c10so6524502wrb.1 for <55023@debbugs.gnu.org>; Thu, 21 Apr 2022 05:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=hoeeJ4yqlgiPHbaWo81brQ7NfYaO3J9/L4MOvjnGEz4=; b=EFq5r0p8f6iwn7o6DGcA7bkhdSnwuR1x/1h7a01BvtshpPWv8YoF368vdaGLS82Dee XheNUxvlnd0HmYstXaL+IYFXfTOF2M1WWyGKLbk9jEe9R0JJF8eVklvqZPn3A3uczUYZ f1mG8VS1OUSzZDHh3qh7wjeByld+emX+7/R3/RPUzYfMUx9SDY/PTgoxu8EqMY1w3LZY yM9QDDrRZjkjRrRIMAKy9TqB+4dTrjc8th6UEcl29MZxP3aCi85M9oPJEvI00tJWd5ya swWHaC89HYP6aImYDJT0vyTrJbyr6GkAPpyxQ9+ec4WchzpDMyF6eCIo7PC3QH24MUTe Rajw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=hoeeJ4yqlgiPHbaWo81brQ7NfYaO3J9/L4MOvjnGEz4=; b=e0XdgWzlr+f2cl841R9XEbH2eOgaFCsSGSUiSwhoAhkK5/jeZ1t61yDvY7Z/SjXn/C 1RzexEzR2foRQcNO6NeKm8fT+fGueBHmZsrYbxJOC8iPBKkfyuwc/eMBeKNnofQi0gmF XUmLopkxZ1cf+3E1em7k5olsv9UrXUfF1s/C+U5fSsy4fLYuwG0fNHEe5QjAFp+qlLza knlgFG/gY48RAJLEe89lvS9LVV9Kd6DQOgv1DB9kAuvtwp801+IFLeNp+4CMeE7FntDo O6a3l83xdewVIIgWN88gOhmtocLbZfl4geLNtQWEcxmTULOeCD3sHJuCeNJhnETm7VGA PGgw== X-Gm-Message-State: AOAM530PHak6iBSBSJ7Kp6MDb3u9lOiv4ZcYoMLauYQX6UGPzY8z8/iF kBKsCgqvpcNL9UsLjzOFnHY= X-Google-Smtp-Source: ABdhPJySUo9azqE3aUYyRTikzozznTLEriiOtKZwkhwMLOFCHJXQ6tZSCh5/MSwPC6qaGmJrJFRWog== X-Received: by 2002:a05:6000:18c9:b0:203:fb67:debe with SMTP id w9-20020a05600018c900b00203fb67debemr19194746wrq.494.1650544574585; Thu, 21 Apr 2022 05:36:14 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id h2-20020a05600c414200b0038ec7a4f07esm1967675wmm.33.2022.04.21.05.36.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 05:36:13 -0700 (PDT) Message-ID: Date: Thu, 21 Apr 2022 13:36:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 19/04/2022 16:01, Arnaud Panaïotis wrote: > 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. That suggests the kernel (statx) returns fine, but glibc is returning the EOVERFLOW. That suggests fstatat() rather than fstatat64() is being used (inferring that by comparing https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat.c https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat64.c) So why is fstatat() being used if compiling with -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 You might confirm what statat is being called with: nm cp | grep U.*statat The redirect from fstatat() in code to the appropriate 64 bit interface should be done with asm redirects and so immune to any undef etc. that gnulib may be doing. So in summary please look at how fstatat() is being referenced on your system (by gnulib). thanks, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 21 10:54:05 2022 Received: (at 55023) by debbugs.gnu.org; 21 Apr 2022 14:54:05 +0000 Received: from localhost ([127.0.0.1]:50648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhYC4-0006GU-Ay for submit@debbugs.gnu.org; Thu, 21 Apr 2022 10:54:04 -0400 Received: from mout.gmx.net ([212.227.15.15]:41221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhYC2-0006Fv-Ap for 55023@debbugs.gnu.org; Thu, 21 Apr 2022 10:54:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650552835; bh=3Y+Jb8w0CcVo548z2OBjObUFe2F5lzDfKQhV3lbPhUE=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=GDZ2luGCKXI8Ng64dM7AWbjuRxckJLrrtTnHsnSjE13BpJF92ND6YJakZuhylO716 ha7cxuLh2m6yVlL7VETUIobTcCMDnnfDlYImAXYxv5d57JLKkZK1ZAjTFE0tX1nkRi mPKelJgCOSZQfHFqZZjE1rR51NJirU9MkpXAXIFs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [100.120.23.223] ([51.158.24.47]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MNKm0-1nX1h232IE-00OqAs; Thu, 21 Apr 2022 16:53:55 +0200 Content-Type: multipart/alternative; boundary="------------m70XVLNEKAJArSmHycWG760Y" Message-ID: <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> Date: Thu, 21 Apr 2022 16:53:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> From: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= In-Reply-To: X-Antivirus: Avast (VPS 220421-0, 21/4/2022), Outbound message X-Antivirus-Status: Clean X-Provags-ID: V03:K1:GzguSLyt84rUfaqlyBQbmw3aIjpoBW5zTBOOw1SQRV56pa/0uga 7Dj4cheSkDGQldmTkCh90Ch0Z/Ybe22GMVJlEz0akEJY1bsSE6208z0NEwwHfmLzkV2pa2E 4WY2Mc7pEQBn2jcyjiDJalXlNfIPYb7JWxmBM/iHdw4cV2K128jdYXWQxCtyBqgSTuLWwSp xSMRRrXIcFt0VbpwEPjSw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:BQzZXl6TE+E=:oNc7leWvae2WQ1Z0LnvwZg s13RvTGDqDUOI/NJyANUh5n1fh8T+BiihGJoa6uJlTjVVlzV1N+eqpOM13ExIZ5pgUAjmMILM E37f5SkfVM7CzIvbm3Fn+9vuPaNFNeSfiLnqn4194gA3XoJzdJQoHoEnOkpUKepvwLuhTLaau qeHUEUGJ7f4Q4TYHqp7AF+9tm7Pjd2Pp/pACnBKh08yidECyOIlr5aD18/+sR8tUG1ErYbLq3 0Fys+YBX4BcArx8SsZNIfvUBLck8/0Q19yU0ln0kHsNXr73M+9TLMoy0QDvyhHQbCnEVcor54 +tfnmcBHZzlHqt/vDxI2MQc0GN1OqveN5uxdr14Am1fLqP/OXypSqBUh1BkdhWHkJSg2nFye5 hV6e40ADhoGjFzjl8QMzZCu8vEkJa/7AtEzL6rVgP6tHwJjCgvsye2AsEsummG2iyToy019r4 oCmTxEsBytWZnWDS9vsSPzwGjK300loLAbTZIAYZs7dYFtMOospgGrpb7PlVPojqbO8PHgUE5 HKTVdquYjAYaqELupUfC3cdgLWisIJPr9GI7fd3MGN1sV1b9dREWPh9VMQe7Hkvxc8SY/QEtT RXtgjX4Wir4SSSnl8jGuU+W5+r0apjXTw28dHfPLvH6z7n81MHzoBd7Qt+UesrVrt1IOc2xP8 YUokxq+cpyKVPNsjIsyjrYfiClr7fYXX0AV736l5kghZB5VMhre6KAtMiY4SDCF0g0YH/oIXH WfaQXHc0Fx5vMZ9P4fkpYPeSPAE3dmEWn0X3UtcCXKOjtzicDFYPbkhIAwQt7nNLftbPAX2aZ Mp5N93ghzSR6vFjRu+UyomH617Ovk/X8kdaUH7IQa7g2QzxtBJoMCmcXVtWGFPbNnjd6fCqhI v3uMqEgeGzO3htwMGd3XjlIT5jUwXDZvGxXpKqCwmbDSTLAVZVRgiYVx34qlT/M2G0EwBvSNe 5k13/ymvQX70Xc3Bcx+5pXnXxt1oG5NbmzfC63kPZs/ZBkG2ihqQ48GVlccJzvXZJRUovIZ8g qnryb1tpZIeKMA/g5TOWt0Dv6dyl3lDcIgfAesPf8HYbUQlP7evbtBUdMAIjM2PzvYzc5QdGE 3At5RtR0+44QB4= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------m70XVLNEKAJArSmHycWG760Y Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 21/04/2022 14:36, P=C3=A1draig Brady wrote: > On 19/04/2022 16:01, Arnaud Pana=C3=AFotis wrote: >> On 19/04/2022 16:00, P=C3=A1draig Brady wrote: >>> On 19/04/2022 08:47, Arnaud Pana=C3=AFotis 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 additiona= l >>>> information if needed. >>>> >>>> I'd like to have a ticket link to follow the advancement of this issu= e >>>> (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=C3=AFotis 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=C2=A0 -D_LARGEFILE_SOURCE >>>>> -D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64 >>>>> >>>>> 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) !=3D 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=3D64 and -D_TIME_BITS=3D64 ar= e >>> defined. >>> >>> An strace of the cp command would be useful to confirm the >>> problematic syscall. > > That suggests the kernel (statx) returns fine, > but glibc is returning the EOVERFLOW. > That suggests fstatat() rather than fstatat64() is being used > (inferring that by comparing > https://sourceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/unix/s= ysv/linux/fstatat.c > > https://sourceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/unix/s= ysv/linux/fstatat64.c) > > > So why is fstatat() being used if compiling with > -D_FILE_OFFSET_BITS=3D64 and -D_TIME_BITS=3D64 > > You might confirm what statat is being called with: > nm cp | grep U.*statat > > The redirect from fstatat() in code to the appropriate 64 bit interface > should be done with asm redirects and so immune to any undef etc. > that gnulib may be doing. > > So in summary please look at how fstatat() is being referenced > on your system (by gnulib). > > thanks, > P=C3=A1draig Hi, I had to add -D option to nm to avoid "no symbols" error. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 U __fstatat64_time64@GLIBC_2.3= 4 All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC. Thanks, =2D- *Arnaud PANA=C3=8FOTIS* | Lead Developer Freelance +33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr > 18 place Jean Moulin - 38000 Grenoble APsudo - www.panaiotis.fr =2D- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. https://www.avast.com/antivirus --------------m70XVLNEKAJArSmHycWG760Y Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 21/04/2022 14:36, P=C3=A1draig Brady wrote:
On 19/04/2022 16:01, Arnaud Pana=C3=AFotis wrote:
On 19/04/2022 16:00, P=C3=A1draig Brady wr= ote:
On 19/04/2022 08:47, Arnaud Pana=C3=AFot= is 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=C3=AFotis 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=C2=A0 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64

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) !=3D 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=3D64 and -D_TIME_BITS=3D64 are defined.

An strace of the cp command would be useful to confirm the problematic syscall.

That suggests the kernel (statx) returns fine,
but glibc is returning the EOVERFLOW.
That suggests fstatat() rather than fstatat64() is being used
(inferring that by comparing
https://so= urceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/unix/sysv/linux/fs= tatat.c
https://= sourceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/unix/sysv/linux/= fstatat64.c)

So why is fstatat() being used if compiling with
-D_FILE_OFFSET_BITS=3D64 and -D_TIME_BITS=3D64

You might confirm what statat is being called with:
nm cp | grep U.*statat

The redirect from fstatat() in code to the appropriate 64 bit interface
should be done with asm redirects and so immune to any undef etc.
that gnulib may be doing.

So in summary please look at how fstatat() is being referenced
on your system (by gnulib).

thanks,
P=C3=A1draig

Hi,

I had to add -D option to nm to avoid "no symbols" error.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 U __fstatat64_time64@G=
LIBC_2.34

All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC.

Thanks,

--

Arnaud PANA=C3=8FOTIS | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr

18 place Jean Moulin - 38000 Grenoble
APsudo - www.= panaiotis.fr


3D"Avast

L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 = v=C3=A9rifi=C3=A9e par le logiciel antivirus Avast.
www.avast.com


--------------m70XVLNEKAJArSmHycWG760Y-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 21 11:25:58 2022 Received: (at 55023) by debbugs.gnu.org; 21 Apr 2022 15:25:58 +0000 Received: from localhost ([127.0.0.1]:50775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhYgv-00010v-JR for submit@debbugs.gnu.org; Thu, 21 Apr 2022 11:25:57 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:37830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhYgu-00010h-RM for 55023@debbugs.gnu.org; Thu, 21 Apr 2022 11:25:57 -0400 Received: by mail-wm1-f48.google.com with SMTP id m15-20020a7bca4f000000b0038fdc1394b1so6125656wml.2 for <55023@debbugs.gnu.org>; Thu, 21 Apr 2022 08:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:cc:from:in-reply-to :content-transfer-encoding; bh=yY+yVqDqraK5Can5PjoJY6DkHkyuV4RML2KV8IBIkWs=; b=qXB2urzOFbPu3wr+1l+oCBBiURPM+VmMRmpaH99kV3bs0s9b5pkXH5Eep04RvwPzbo fgOD/P21EbQ8o74GXcXCKzMscMseH0x2OS5l6enP+0pP3rPjmrwrzUK4TUUbvK3YUhQc kkIW2rV2EtgX7IFTgZVi9TOWuHD6qog9xbQnZPAnvmaCrbbDGC/n6oCoXZpDv8coXF+T U4RdLG88FNIoA41DmYJMKbxwOaocelv9g/nPDiCIaocvc59ULjNVwy8Ez1pxvnoewVdU Ghn8sBquesVHF0Fw8eXLkfLTPf0jCHoAXdjOlvW9OU/MxA/CFkymDl0F8HKn+ROVBgnz zoZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:cc:from:in-reply-to :content-transfer-encoding; bh=yY+yVqDqraK5Can5PjoJY6DkHkyuV4RML2KV8IBIkWs=; b=wZRdK/AnlHnST/4ntEKXRN05Gn6aXWITZYZqKHL+HgOJCCodpU2Owzaq5Z1CZYJxw/ EO2Dpg1lKB+NUIjH0jYtqwel71MQm5Hq22exxzkm/aNGBWk+lc1vrBx/ohVKeykndY7M UtxAk1zDAMC8jp3G2BYynKrR8QQ1EOJXgjhJxuBoiOPxePtrEW1oqSZC/LgyR/M1NuO3 J65dlLhoAzcBT79aoyxDn0N2yvVm/zKtSMkyKtk6uVpcFvVIUrT/agtAvfQoFkMxh1z5 H0xYgkT8SP0gYNOpHHAd0B4yTvD1KBiXhB8bU4PGUx0oUoQGP26T16rIy/mgmvy1+xuy I4hQ== X-Gm-Message-State: AOAM532ZYcam5tm8ZavkPx7BrouhjLQtN2zB30BstE/H3kS+0HA9PjH6 MECe+lOqZOAJwiSAh9+pXOc= X-Google-Smtp-Source: ABdhPJzHPeymu78QIUO4Uf/woAtqjrI9gZeSRZmoBAZkCrT0uPbD5LnJIP9I+fcj1XB1oVd1CrsCHA== X-Received: by 2002:a1c:e916:0:b0:38e:ac96:f477 with SMTP id q22-20020a1ce916000000b0038eac96f477mr9250913wmc.160.1650554750874; Thu, 21 Apr 2022 08:25:50 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id j14-20020a05600c190e00b00392910b276csm3106698wmq.27.2022.04.21.08.25.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 08:25:50 -0700 (PDT) Message-ID: <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> Date: Thu, 21 Apr 2022 16:25:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55023 Cc: Adhemerval Zanella X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 21/04/2022 15:53, Arnaud Panaïotis wrote: > > On 21/04/2022 14:36, Pádraig Brady wrote: >> On 19/04/2022 16:01, Arnaud Panaïotis wrote: >>> 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. >> >> That suggests the kernel (statx) returns fine, >> but glibc is returning the EOVERFLOW. >> That suggests fstatat() rather than fstatat64() is being used >> (inferring that by comparing >> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat.c >> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat64.c) >> >> So why is fstatat() being used if compiling with >> -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 >> >> You might confirm what statat is being called with: >> nm cp | grep U.*statat >> >> The redirect from fstatat() in code to the appropriate 64 bit interface >> should be done with asm redirects and so immune to any undef etc. >> that gnulib may be doing. >> >> So in summary please look at how fstatat() is being referenced >> on your system (by gnulib). >> >> thanks, >> Pádraig > > Hi, > > I had to add -D option to nm to avoid "no symbols" error. > >         U __fstatat64_time64@GLIBC_2.34 > > All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC. That looks correct. So perhaps the EOVERFLOW is within your glibc's fstatat64 implementation? You might get to the issue more quickly by installing debug symbols for your coreutils and/or glibc and using: gdb -tui -args cp rest of cp args thanks, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 21 16:59:14 2022 Received: (at 55023) by debbugs.gnu.org; 21 Apr 2022 20:59:15 +0000 Received: from localhost ([127.0.0.1]:50999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhdtS-0005U5-Gs for submit@debbugs.gnu.org; Thu, 21 Apr 2022 16:59:14 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:39867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhdtQ-0005Tp-7J for 55023@debbugs.gnu.org; Thu, 21 Apr 2022 16:59:13 -0400 Received: by mail-wm1-f44.google.com with SMTP id ay11-20020a05600c1e0b00b0038eb92fa965so6663935wmb.4 for <55023@debbugs.gnu.org>; Thu, 21 Apr 2022 13:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Yn8HASbmPjlkFK6WIUtFaOKgmkeb/Ab9yTSlx2maQw8=; b=pair9B/B/HofoixDefb++EB9QzX1eGb5xx8lEKn1OEBYD622qrIkVjKWlbhcvN4BAw Vy9ghO2Rr1mLcvUSCQXnxARpZLg3qOUou9fPQwqLT6aFTKPBAFUOP8X+It0b+Byfxp87 vQFUCsAHD/JTJaaTGKSuHeVSLwLY8A+QcwIwtxHmxihUcgHTFkRxecitwGG6cTatm0Sh Y1Jr012nncs9i29Vt7VKrvAbipyCuNoEVxAQCzxL5Rjf1UvvnLhtvbKgO+QzVNFL2rox MdqAdU6TrXDtWsFj1RoVvrxzI9scPKq9rYo6OLPe7gBNAfODff5mAYcn3JMPeix2DqDw qPog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Yn8HASbmPjlkFK6WIUtFaOKgmkeb/Ab9yTSlx2maQw8=; b=WdyTiZShbZ26GG7Gcm4ZoZPeFYCnXteps9KNSsb75mBzfAroy7NaDKtPzVUmoua5Q0 oLmHKfS4E6jQ1Xm56Fk7BRXxBDycUEgS3gZy5VxOBkNMUm0n6tiHnstFeQsDMUxeVToq CCTigJ5CP66pa30ckF+Yx7URNo0xIyM0YukRqOUGUyz5ucibAtzgflD4OR+sYFRfdkdn Hu5AdEbhrUSL/8OfNUp1uJYu1rN17BewUzgE5jv/lM3z782obBsBJUivrSm9Hq5+O9aC 5oyH0wPoLs4IMh+SFmfDmpncvzzn0MVoyeRNMeviWxjNv0oqkls/O6BrD4vqp4mJU0tl IT+g== X-Gm-Message-State: AOAM533ppaNI3vOhvd+1ahtp0FPYRz1acMp6RmxjOP1j/PCRuAbCZfCm YisZ4e6k7a/VlizTVRXn/zc= X-Google-Smtp-Source: ABdhPJxQLaB0CFCn5TaxIQ7sKFTAIRwGX0BaQZNQKnk04QOPeXCEziyIOwBTExKPjLELunMjZ2iZJA== X-Received: by 2002:a1c:2b82:0:b0:392:5bfb:a0e1 with SMTP id r124-20020a1c2b82000000b003925bfba0e1mr1073489wmr.36.1650574745995; Thu, 21 Apr 2022 13:59:05 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id c3-20020a05600c148300b0038ebc8ad740sm3334995wmh.1.2022.04.21.13.59.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 13:59:05 -0700 (PDT) Message-ID: Date: Thu, 21 Apr 2022 21:59:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: Adhemerval Zanella , =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 21/04/2022 18:41, Adhemerval Zanella wrote: > > > On 21/04/2022 12:25, Pádraig Brady wrote: >> On 21/04/2022 15:53, Arnaud Panaïotis wrote: >>> >>> On 21/04/2022 14:36, Pádraig Brady wrote: >>>> On 19/04/2022 16:01, Arnaud Panaïotis wrote: >>>>> 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. >>>> >>>> That suggests the kernel (statx) returns fine, >>>> but glibc is returning the EOVERFLOW. >>>> That suggests fstatat() rather than fstatat64() is being used >>>> (inferring that by comparing >>>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat.c >>>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat64.c) >>>> >>>> So why is fstatat() being used if compiling with >>>> -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 >>>> >>>> You might confirm what statat is being called with: >>>> nm cp | grep U.*statat >>>> >>>> The redirect from fstatat() in code to the appropriate 64 bit interface >>>> should be done with asm redirects and so immune to any undef etc. >>>> that gnulib may be doing. >>>> >>>> So in summary please look at how fstatat() is being referenced >>>> on your system (by gnulib). >>>> >>>> thanks, >>>> Pádraig >>> >>> Hi, >>> >>> I had to add -D option to nm to avoid "no symbols" error. >>> >>>          U __fstatat64_time64@GLIBC_2.34 >>> >>> All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC. >> >> That looks correct. >> >> So perhaps the EOVERFLOW is within your glibc's fstatat64 implementation? >> You might get to the issue more quickly by installing debug symbols for >> your coreutils and/or glibc and using: gdb -tui -args cp rest of cp args >> > > Assuming a default config option (without --enable-kernel) the > _fstatat64_time64 should first try statx and then the old fstatat64 > if statx fails with ENOSYS (on kernel older than 4.11). The EOVERFLOW > only happens for later, assuming kernel does not returns anything > bogus. > > What strace shows in this scenario? strace shows statx() returning non error on this 5.15 kernel From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 02:24:43 2022 Received: (at 55023) by debbugs.gnu.org; 22 Apr 2022 06:24:43 +0000 Received: from localhost ([127.0.0.1]:51309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhmih-0004EF-1l for submit@debbugs.gnu.org; Fri, 22 Apr 2022 02:24:43 -0400 Received: from mail-ot1-f45.google.com ([209.85.210.45]:46738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhaoE-0008AH-SG for 55023@debbugs.gnu.org; Thu, 21 Apr 2022 13:41:39 -0400 Received: by mail-ot1-f45.google.com with SMTP id t6-20020a056830224600b00605491a5cd7so3736761otd.13 for <55023@debbugs.gnu.org>; Thu, 21 Apr 2022 10:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=fYnbXgK5MY8p7FP+ydL8Zx3VWnxeCyUHudEFE6ooots=; b=C+ouamUf7A+AsBVMwrIBwLpJHLGtDdiigbEg88pWR//HLT/lcdQYi07KeCbfLHx6yq 5LG629/f7xOEOkBvBCt3ra9vhnxRc+zwSVjJ5G22TGuyarHWusHMZQHbtu4WnAcNMC5t i9nCZv6ZGhvfEpxJ+l3VXN/d6o/uzJp7wLxaY6PainBoeKpY1K/UzRnbPDtdSiFsGueR Jw/Hr51iHJgst/mb32a7i8UdLXYfLbyzmYUxrI7RLzmWf7Jw+BN2gVG1rGb30eAZBgOW 6UcJWcwqZe5kk9uCBAZoqeNAl01x2sMzrJdmRq1g9PZlCtl2omC6wbmEGt3z+GXssY9g ljCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=fYnbXgK5MY8p7FP+ydL8Zx3VWnxeCyUHudEFE6ooots=; b=wE71ufwlXJmaB1/RI+2fVDKu9KYMHDzfIFpYxJa47MU0Cz2R8USOlCwFZ7I69qes7r Q3mXgKa298D3FYXbH7ONgKqjscNrCNIGf0TINtpWJKDj6PfDrNHwSh5qhT9LQaFY+JYA DocMdnqC6pa4mHah3TZKHYTUv5y7qMGLy5xEgYG/8DHxITg7nXHwbzM2idyDTGdwX08h 9JUk/Fy1YqPqZDNK9+hRlAsERjqAlPOY9c7thBc1emQFSqI5sPVDd73ajTWz5oxqDDL5 ED7T0hUMclhwh8hU9eOx1+q7K6RiNWbkaKXbt8Sqq5qVABNKtJ4f8sJEH1fxFQN7H9Vo 6Nxw== X-Gm-Message-State: AOAM531sIg1D/m8ZqhpJantd7+VHm3HtJOdi4mueb9fabEyixL823f6f 98yboRWCJ67bL0LD+KWy7uYlJ1VelIgYkg== X-Google-Smtp-Source: ABdhPJwgqpH700T+IEVSokHzuDuRbJV1sLtvQYiP3zRG/xpIxdwpv9kZRAUCLWZk0rYnu09O1uSHmA== X-Received: by 2002:a05:6830:1da4:b0:605:4f50:6aa with SMTP id z4-20020a0568301da400b006054f5006aamr368554oti.59.1650562892973; Thu, 21 Apr 2022 10:41:32 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:c9d0:4761:3591:6c37:ad26? ([2804:431:c7ca:c9d0:4761:3591:6c37:ad26]) by smtp.gmail.com with ESMTPSA id n35-20020a05687055a300b000e1e2ab91e4sm1248131oao.39.2022.04.21.10.41.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 10:41:32 -0700 (PDT) Message-ID: <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> Date: Thu, 21 Apr 2022 14:41:29 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= , =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> From: Adhemerval Zanella In-Reply-To: <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55023 X-Mailman-Approved-At: Fri, 22 Apr 2022 02:24:41 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 21/04/2022 12:25, Pádraig Brady wrote: > On 21/04/2022 15:53, Arnaud Panaïotis wrote: >> >> On 21/04/2022 14:36, Pádraig Brady wrote: >>> On 19/04/2022 16:01, Arnaud Panaïotis wrote: >>>> 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. >>> >>> That suggests the kernel (statx) returns fine, >>> but glibc is returning the EOVERFLOW. >>> That suggests fstatat() rather than fstatat64() is being used >>> (inferring that by comparing >>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat.c >>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat64.c) >>> >>> So why is fstatat() being used if compiling with >>> -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 >>> >>> You might confirm what statat is being called with: >>> nm cp | grep U.*statat >>> >>> The redirect from fstatat() in code to the appropriate 64 bit interface >>> should be done with asm redirects and so immune to any undef etc. >>> that gnulib may be doing. >>> >>> So in summary please look at how fstatat() is being referenced >>> on your system (by gnulib). >>> >>> thanks, >>> Pádraig >> >> Hi, >> >> I had to add -D option to nm to avoid "no symbols" error. >> >>          U __fstatat64_time64@GLIBC_2.34 >> >> All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC. > > That looks correct. > > So perhaps the EOVERFLOW is within your glibc's fstatat64 implementation? > You might get to the issue more quickly by installing debug symbols for > your coreutils and/or glibc and using: gdb -tui -args cp rest of cp args > Assuming a default config option (without --enable-kernel) the _fstatat64_time64 should first try statx and then the old fstatat64 if statx fails with ENOSYS (on kernel older than 4.11). The EOVERFLOW only happens for later, assuming kernel does not returns anything bogus. What strace shows in this scenario? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 08:44:52 2022 Received: (at 55023) by debbugs.gnu.org; 26 Apr 2022 12:44:52 +0000 Received: from localhost ([127.0.0.1]:37524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njKYl-0002rW-9p for submit@debbugs.gnu.org; Tue, 26 Apr 2022 08:44:52 -0400 Received: from mout.gmx.net ([212.227.17.21]:48627) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njKYf-0002r0-0Y for 55023@debbugs.gnu.org; Tue, 26 Apr 2022 08:44:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650977077; bh=DdHbD0T8AtkQ7cU+ysfiV+lbu3iTSbZjvMb9x8hpXP0=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=KBAFAb7PD+2mLXB8H8VLyqokppZI1aVEcKt+gmEYHzW57stdkqFQNZbjGs0z7oTMk RBCRxBwTjMesVHDDviMrEEYB07kJnmyn008drWblX0eKaill7Qyn/Hl5uvZEO3YBXT JdcjMUhRgdTEh1esv+bXunwr6DLyEDiNK3o2PkSM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [100.120.78.214] ([212.129.33.184]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MKbg4-1nSl6v2J0G-00L0XQ; Tue, 26 Apr 2022 14:44:37 +0200 Content-Type: multipart/alternative; boundary="------------SpXrv9goSB4hJL7lnt2dxeqy" Message-ID: <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> Date: Tue, 26 Apr 2022 14:44:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= , Adhemerval Zanella , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> From: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= In-Reply-To: X-Antivirus: Avast (VPS 220426-0, 26/4/2022), Outbound message X-Antivirus-Status: Clean X-Provags-ID: V03:K1:Btd4xgj69vs1cBOhbQJsPDC3g+nIpTSajd5GxB9HVHVk+b3n00W D4DV5NDDLRp60lDBHzU20Bmg5x+ugirQrKuhHzNe0bxppl4FEFT0NOprY9LKaY9j4oLwEem 8kQ5sOLjprGRJuFiafELiuAYquvyJua6C4ykr4i0hiZqY8HMPoSiWcS4CMR28/rGG9KL87x x58bxuh5q1BMc3/Ydxkiw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:JV1Dj27/730=:Imab7hIx4jfCRBZ/0yc6iU k/lpo1OWn4eoD7rhPp2J/kxBgKSYYZ5qeM1f6XNi3ehis6KrQNkw/6EUEMEu7TKG0DAL3AIaG dF7fSul7Q9QppjDp3IG3ynUkV3osaUyEarGSIWTLVsG0HQn+EYk2XJXWMpIYPIormjKvwvoV9 5dZByA4fZSFC7lHLtWku7INkdpvqwxMUlfF06CHMb6go3v8U1FmQ9VwC/uorme6RJEp8eJsLn 4uG1gNCjXxscNeDN21WHKwgHsXmfcfnbZkQJh4U9SCHkbwp8uJva4VYJXLpsrIatgZNm5FPNf Lv1t7JkfLs+zqLrJbx0wXH11z8aTWATfQr8/NYEvkkwZSUAgFTeCELr0wtTR9gs089iKWL/B1 k00pPXxRVVsD6a9/51m/6GxKuh929rlyiiIxYSi4S7sLVyhk1OhJ7vkutG3LtVfWTyEuy4jSz tum8erXPQDhh7YuJJsFjYtL3KvZBxK7HmFAqmqhtoeR4gTSRGLGVsTZHFBEM+1tl5aYfFL7yW QjeuF9oaXbVLaOhycp5zv4uaVarPcszGce1hKsWq7B5Tnc7kuGKy5HlDFX3loKHh5rr2I5RD/ mMMqxQYKJ2DGDLhUikWpEqd3hzqQqET0b23KLCGfOl+ie+G8JtIBz7Q8xo/iBC4ASnI5IREpH a5ju000DoYuKvI22wxxFaSTMIVBrbyyrPey/d4yitvXRaHEY+iN2ZM+zCshIJwCdx3zrWDSwH w7OY3YcDIiXQ/18T8JPOO+I6ybutQDEgH8CTuAnHEy6B7cSOMjNCoSzM8NF3qJTXtg/uFhRWK plKAwaS4kbkVc0AnuOwoDjDzRpjGwz4sl9kRCdb7GSKIPG+cHnMQK6kSLWPWkV7edUzunpQMW td3gcxKJWO4eCZ9Yd3Z6JPc9piiyV6cBjxhij82f+NsY9zNj0w0kCvnMV4zxNUpvQJG8G9r90 vYNUZikl/YZuN54Blunv/6gN2g3FMc8XDbVFRSs+cUP2vWM9g5aVV90MU/IcrlXmgkugHNF3x pmXPTpCDk90Wz2idILA0g1gHX9AvSGHgron8KdEHizlFy4TzhO6bF5eV0LjXEU+6xAHkUavK8 idoZjKsBLcx3dI= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------SpXrv9goSB4hJL7lnt2dxeqy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 21/04/2022 22:59, P=C3=A1draig Brady wrote: > On 21/04/2022 18:41, Adhemerval Zanella wrote: >> >> >> On 21/04/2022 12:25, P=C3=A1draig Brady wrote: >>> On 21/04/2022 15:53, Arnaud Pana=C3=AFotis wrote: >>>> >>>> On 21/04/2022 14:36, P=C3=A1draig Brady wrote: >>>>> On 19/04/2022 16:01, Arnaud Pana=C3=AFotis wrote: >>>>>> On 19/04/2022 16:00, P=C3=A1draig Brady wrote: >>>>>>> On 19/04/2022 08:47, Arnaud Pana=C3=AFotis 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=C3=AFotis 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=3D64=C2=A0 -D_TIME_BITS=3D64 >>>>>>>>> >>>>>>>>> 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) !=3D 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=3D64 and -D_TIME_BITS=3D6= 4 >>>>>>> are defined. >>>>>>> >>>>>>> An strace of the cp command would be useful to confirm the >>>>>>> problematic syscall. >>>>> >>>>> That suggests the kernel (statx) returns fine, >>>>> but glibc is returning the EOVERFLOW. >>>>> That suggests fstatat() rather than fstatat64() is being used >>>>> (inferring that by comparing >>>>> https://sourceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/un= ix/sysv/linux/fstatat.c >>>>> >>>>> https://sourceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/un= ix/sysv/linux/fstatat64.c) >>>>> >>>>> >>>>> So why is fstatat() being used if compiling with >>>>> -D_FILE_OFFSET_BITS=3D64 and -D_TIME_BITS=3D64 >>>>> >>>>> You might confirm what statat is being called with: >>>>> nm cp | grep U.*statat >>>>> >>>>> The redirect from fstatat() in code to the appropriate 64 bit >>>>> interface >>>>> should be done with asm redirects and so immune to any undef etc. >>>>> that gnulib may be doing. >>>>> >>>>> So in summary please look at how fstatat() is being referenced >>>>> on your system (by gnulib). >>>>> >>>>> thanks, >>>>> P=C3=A1draig >>>> >>>> Hi, >>>> >>>> I had to add -D option to nm to avoid "no symbols" error. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 U __fstatat64_= time64@GLIBC_2.34 >>>> >>>> All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC. >>> >>> That looks correct. >>> >>> So perhaps the EOVERFLOW is within your glibc's fstatat64 >>> implementation? >>> You might get to the issue more quickly by installing debug symbols fo= r >>> your coreutils and/or glibc and using: gdb -tui -args cp rest of cp >>> args >>> >> >> Assuming a default config option (without --enable-kernel) the >> _fstatat64_time64 should first try statx and then the old fstatat64 >> if statx fails with ENOSYS (on kernel older than 4.11).=C2=A0 The EOVER= FLOW >> only happens for later, assuming kernel does not returns anything >> bogus. >> >> What strace shows in this scenario? > > strace shows statx() returning non error on this 5.15 kernel Hi, Sorry for the delay, had trouble to generate all requirements within Buildroot (now with gdb+coreutils debugs). I can add glibc debug if needed= . quotearg_buffer_restyled (buffer=3Dbuffer@entry=3D0x41b5a0 "", buffersize=3D, buffersize@entry=3D256, arg=3Darg@entry=3D0x41c5f0 "folder/test1", argsize=3D4294967295, =C2=A0 =C2=A0 quoting_style=3D, flags=3D, quote_these_too=3D, left_quote=3D0x0, right_quote=3D0x0) at lib/quotearg.c:262 (gdb) quotearg_n_options (n=3Dn@entry=3D0, arg=3Darg@entry=3D0x41c5f0 "folder/te= st1", argsize=3Dargsize@entry=3D4294967295, options=3D0xbffff630) at lib/quotearg.c:905 0x00406b46 in copy_reg (src_sb=3D, new_dst=3D, omitted_permissions=3D, dst_mode=3D, x=3D, dst_name=3D, =C2=A0 =C2=A0 src_name=3D) at src/copy.c:1146 /bin/cp: setting permissions for 'folder/test1': Value too large for defin= ed data type I don't have layout src working but layout asm works. (breakpoint at fstatat, then step by step). Let me know if you need more details, I'm available for a shared screen visio if needed (I'm in UTC+2). Best regards, =2D- *Arnaud PANA=C3=8FOTIS* | Lead Developer Freelance +33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr > 18 place Jean Moulin - 38000 Grenoble APsudo - www.panaiotis.fr =2D- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. https://www.avast.com/antivirus --------------SpXrv9goSB4hJL7lnt2dxeqy Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 21/04/2022 22:59, P=C3=A1draig Brady wrote:
On 21/04/2022 18:41, Adhemerval Zanella wrote:


On 21/04/2022 12:25, P=C3=A1draig Brady wrote:
On 21/04/2022 15:53, Arnaud Pana=C3=AFot= is wrote:

On 21/04/2022 14:36, P=C3=A1draig Brady wrote:
On 19/04/2022 16:01, Arnaud Pana=C3=AFotis wrote:
On 19/04/2022 16:00, P=C3=A1draig = Brady wrote:
On 19/04/2022 08:47, Arnaud Pana=C3=AFotis 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=C3=AFotis 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=C2=A0 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=3D64=C2=A0 -D_TIME_BITS=3D64

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) !=3D 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=3D64 and -D_TIME_BITS=3D64 are defined.

An strace of the cp command would be useful to confirm the problematic syscall.

That suggests the kernel (statx) returns fine,
but glibc is returning the EOVERFLOW.
That suggests fstatat() rather than fstatat64() is being used
(inferring that by comparing
https://so= urceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/unix/sysv/linux/fs= tatat.c
https://= sourceware.org/git/?p=3Dglibc.git;a=3Dhistory;f=3Dsysdeps/unix/sysv/linux/= fstatat64.c)

So why is fstatat() being used if compiling with
-D_FILE_OFFSET_BITS=3D64 and -D_TIME_BITS=3D64

You might confirm what statat is being called with:
nm cp | grep U.*statat

The redirect from fstatat() in code to the appropriate 64 bit interface
should be done with asm redirects and so immune to any undef etc.
that gnulib may be doing.

So in summary please look at how fstatat() is being referenced
on your system (by gnulib).

thanks,
P=C3=A1draig

Hi,

I had to add -D option to nm to avoid "no symbols" error.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 U __fst= atat64_time64@GLIBC_2.34

All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC.

That looks correct.

So perhaps the EOVERFLOW is within your glibc's fstatat64 implementation?
You might get to the issue more quickly by installing debug symbols for
your coreutils and/or glibc and using: gdb -tui -args cp rest of cp args


Assuming a default config option (without --enable-kernel) the
_fstatat64_time64 should first try statx and then the old fstatat64
if statx fails with ENOSYS (on kernel older than 4.11).=C2=A0 The EOVERFLOW
only happens for later, assuming kernel does not returns anything
bogus.

What strace shows in this scenario?

strace shows statx() returning non error on this 5.15 kernel
Hi,

Sorry for the delay, had trouble to generate all requirements within Buildroot (now with gdb+coreutils debugs). I can add glibc debug if needed.

quotearg_buffer_restyled (buffer=3Dbuffer@entry=3D0x41b5a0 <=
slot0> "",
 buffersize=3D<optimized out>, buffersize@entry=3D256,
arg=3Darg@entry=3D0x41c5f0 "folder/test1", argsize=3D4294967295,
=C2=A0 =C2=A0 quoting_style=3D<optimized out>, flags=3D<optimized=
 out>,
quote_these_too=3D<optimized out>, left_quote=3D0x0, right_quote=3D0=
x0)
at lib/quotearg.c:262
(gdb)
quotearg_n_options (n=3Dn@entry=3D0, arg=3Darg@entry=3D0x41c5f0 "folder/te=
st1",
argsize=3Dargsize@entry=3D4294967295, options=3D0xbffff630) at
lib/quotearg.c:905
0x00406b46 in copy_reg (src_sb=3D<optimized out>,
new_dst=3D<optimized out>, omitted_permissions=3D<optimized
out>, dst_mode=3D<optimized out>, x=3D<optimized out>,
dst_name=3D<optimized out>,
=C2=A0 =C2=A0 src_name=3D<optimized out>) at src/copy.c:1146
/bin/cp: setting permissions for 'folder/test1': Value too large for defin=
ed data type
I don't have layout src working but layout asm works.

(breakpoint at fstatat, then step by step).

Let me know if you need more details, I'm available for a shared screen visio if needed (I'm in UTC+2).

Best regards,

--

Arnaud PANA=C3=8FOTIS | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr

18 place Jean Moulin - 38000 Grenoble
APsudo - www.= panaiotis.fr


3D"Avast

L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 = v=C3=A9rifi=C3=A9e par le logiciel antivirus Avast.
www.avast.com


--------------SpXrv9goSB4hJL7lnt2dxeqy-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 12:42:56 2022 Received: (at 55023-done) by debbugs.gnu.org; 27 Apr 2022 16:42:56 +0000 Received: from localhost ([127.0.0.1]:44066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njkkh-0003Nx-Tl for submit@debbugs.gnu.org; Wed, 27 Apr 2022 12:42:56 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:55851) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njkkg-0003Nl-LE for 55023-done@debbugs.gnu.org; Wed, 27 Apr 2022 12:42:55 -0400 Received: by mail-wm1-f53.google.com with SMTP id m62so1474911wme.5 for <55023-done@debbugs.gnu.org>; Wed, 27 Apr 2022 09:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=tqOF8KZxXbpLhyEolw9wFJCRh9dE6hD3gNFd5Vrjr4M=; b=DnCsMUKtszDokyeced1LnXefsDJkWL7BW7vMJ1fevBURK3I3kH5YGWNR+B/Rbgf8Id TXsiqFQ0KbN+h6x0SYbc1hqU3CbIvuUi17+rpeZpNdpz6KHARNvqJeaksjdlY2zccnEg RJk7buSDF2oX58FJJBQI478grhjwP0IqaNkxr0TVOUi9GOoh9JdaMkwjo4dHhCzSZ2aZ 3KmhBvD1L0iebg2fvkJEt3dqVhZLluxW8xHUVZGYPPo8pHYVxUnyZe5di/lt31dA29rt 1u0trFP3kl0EBB8K8mFCUy330byRZ9a4Fb8GNb2HRLRGEWoSbqZsGNtNVVBnQ0s2Uuso nf5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=tqOF8KZxXbpLhyEolw9wFJCRh9dE6hD3gNFd5Vrjr4M=; b=nLfLzVgp3ELlq7HO2hNfjLoYLBYt39KbGHHhG00Qoo7+7M9mIK2p7ACy87FIZdoAty 9My5FtMu21fWVSdslcRRtG44mDDLCTwh3Bh43OxkH5+vjPp+wm72thuQzh++vpED4cKj fbKsg2cyuWQE56fKV3oIuqtJ3WNvproT0s8k+QiTfyEQQBSupP32M548cq+C0gmI3GwL KehUW/+K0vyeQx33Z3NqvRZIZnXLD3ob3usW0fu+0fuzpEY8KAyw87R5sDJCkQMnJ7pj cxh+T6qhL0/LUmKwcOc0j3sir8ozQMUv3s//+tiyLOC++9RzIQi4P0bLC9bxD6KQpJ86 VOvQ== X-Gm-Message-State: AOAM533xKgxVP0JN/SukiDQqL00jg8/uDNd7OIjIEViKGSDI9AYTSr1F 0w6h4hAzDEES9Xw3zoC24qk= X-Google-Smtp-Source: ABdhPJxpYDgLS1ypNTlENq9wqarAONBXHUlaksGb5AmXRafR1MtbscT/+4A23lfY+QkN86Bo1KJKgw== X-Received: by 2002:a05:600c:4347:b0:393:fbae:a5da with SMTP id r7-20020a05600c434700b00393fbaea5damr7288926wme.205.1651077768745; Wed, 27 Apr 2022 09:42:48 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id r184-20020a1c2bc1000000b00392af6f0ab0sm1935127wmr.18.2022.04.27.09.42.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Apr 2022 09:42:48 -0700 (PDT) Message-ID: <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com> Date: Wed, 27 Apr 2022 17:42:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: Adhemerval Zanella , =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023-done@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> <473a02d7-0d1d-4dec-8ca2-18fa32a248a9@linaro.org> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <473a02d7-0d1d-4dec-8ca2-18fa32a248a9@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55023-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 17:42:02 2022 Received: (at 55023) by debbugs.gnu.org; 27 Apr 2022 21:42:02 +0000 Received: from localhost ([127.0.0.1]:44648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njpQ9-00061c-Qa for submit@debbugs.gnu.org; Wed, 27 Apr 2022 17:42:02 -0400 Received: from mail-oi1-f172.google.com ([209.85.167.172]:46072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njh4L-0008U6-Uf for 55023@debbugs.gnu.org; Wed, 27 Apr 2022 08:46:58 -0400 Received: by mail-oi1-f172.google.com with SMTP id 12so1771194oix.12 for <55023@debbugs.gnu.org>; Wed, 27 Apr 2022 05:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=salSLglC1b5AKCLCrRwcCFWkIRl7rqfKEadojW7qKzk=; b=VNNb0JJwZ5rhIJW7LnA7MCwc+yle2YCdnvL1Y09BlN417dQswdGYKQGd98cjzhHzD7 n5qGRb3TWZqA9lDakQRsigvqBaP46QtV92ZbKWP83Wd0QLrFOixZCFYMBrYPBBe4NPrA jK0nehEO/IiWeO9iuT9C5OrehUKSy84sX2/XsUw2s3xLQJh5o9cqF1tLYs7MDgRS3JQg 5+w+DC6uE7Hq1JDA6nJfcTcOFJsQF2B0A+A1rfUrMzYrkN5UO+VdB/PzNzPN49zgKx8k c3TA2BcK8RzR3xGOWkm8zxNin8d1HNS8tcczt29Lb7GZQY1w+uIG5r/gX4YiQPcQSwhi avGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=salSLglC1b5AKCLCrRwcCFWkIRl7rqfKEadojW7qKzk=; b=pYWliKoBM9ClXlFz2rVgTULcXcCTLC8hUUivnzXFJpKfAGBbn/oHY4gkuXWDD3/DF3 ktMtuBtwM6D1yxM6AFOjLE9XMl6x/YGnNb79e6FASwz032My8WTHe2PmkPHWavgV5HHH 87bH+raPhEL0ysBKhtgJ9x+nKRx19cJKMDSQ+bupSmgGlRngM8U69PeZjbkiaYGEHBhp wHYYCTH03gYIytsDDVPMIdKaWuUhvTxOtphhxR9JOqn1M4/EF3Ec+xDi4FAfO71rLsPB 9vUBVfGMS5iwfyz8Q2b3NiSjvaPDBs1RJWK7ZtraBZR/dhAAfZJ3FbRTJ0HORj6gPdnu m2XA== X-Gm-Message-State: AOAM530G5xRGzDG77W6hUlZlSQLkjzn/OWbIM8Pv1ywtqQsQDAsM1hxN rMy5f0PPlmT1XduUr4bgMjNg3lNoAIoGFw== X-Google-Smtp-Source: ABdhPJyqBNQGzEGipuejPMfylYZIn+S3cC2ISgZUyb4sGDY+QiimzQHEL4pzOZbl/SNixFuQqUTUHg== X-Received: by 2002:a05:6808:1819:b0:322:9337:9030 with SMTP id bh25-20020a056808181900b0032293379030mr13048055oib.297.1651063611928; Wed, 27 Apr 2022 05:46:51 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:4214:b613:182d:cdde:5f86? ([2804:431:c7ca:4214:b613:182d:cdde:5f86]) by smtp.gmail.com with ESMTPSA id y6-20020a4a86c6000000b0033a64ed2074sm6640536ooh.19.2022.04.27.05.46.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Apr 2022 05:46:51 -0700 (PDT) Message-ID: <473a02d7-0d1d-4dec-8ca2-18fa32a248a9@linaro.org> Date: Wed, 27 Apr 2022 09:46:48 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , =?UTF-8?Q?P=c3=a1draig_Brady?= , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> From: Adhemerval Zanella In-Reply-To: <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55023 X-Mailman-Approved-At: Wed, 27 Apr 2022 17:42:01 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 26/04/2022 09:44, Arnaud Panaïotis wrote: > > On 21/04/2022 22:59, Pádraig Brady wrote: >> On 21/04/2022 18:41, Adhemerval Zanella wrote: >>> >>> >>> On 21/04/2022 12:25, Pádraig Brady wrote: >>>> On 21/04/2022 15:53, Arnaud Panaïotis wrote: >>>>> >>>>> On 21/04/2022 14:36, Pádraig Brady wrote: >>>>>> On 19/04/2022 16:01, Arnaud Panaïotis wrote: >>>>>>> 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. >>>>>> >>>>>> That suggests the kernel (statx) returns fine, >>>>>> but glibc is returning the EOVERFLOW. >>>>>> That suggests fstatat() rather than fstatat64() is being used >>>>>> (inferring that by comparing >>>>>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat.c >>>>>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat64.c) >>>>>> >>>>>> So why is fstatat() being used if compiling with >>>>>> -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 >>>>>> >>>>>> You might confirm what statat is being called with: >>>>>> nm cp | grep U.*statat >>>>>> >>>>>> The redirect from fstatat() in code to the appropriate 64 bit interface >>>>>> should be done with asm redirects and so immune to any undef etc. >>>>>> that gnulib may be doing. >>>>>> >>>>>> So in summary please look at how fstatat() is being referenced >>>>>> on your system (by gnulib). >>>>>> >>>>>> thanks, >>>>>> Pádraig >>>>> >>>>> Hi, >>>>> >>>>> I had to add -D option to nm to avoid "no symbols" error. >>>>> >>>>>           U __fstatat64_time64@GLIBC_2.34 >>>>> >>>>> All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC. >>>> >>>> That looks correct. >>>> >>>> So perhaps the EOVERFLOW is within your glibc's fstatat64 implementation? >>>> You might get to the issue more quickly by installing debug symbols for >>>> your coreutils and/or glibc and using: gdb -tui -args cp rest of cp args >>>> >>> >>> Assuming a default config option (without --enable-kernel) the >>> _fstatat64_time64 should first try statx and then the old fstatat64 >>> if statx fails with ENOSYS (on kernel older than 4.11).  The EOVERFLOW >>> only happens for later, assuming kernel does not returns anything >>> bogus. >>> >>> What strace shows in this scenario? >> >> strace shows statx() returning non error on this 5.15 kernel > Hi, > > Sorry for the delay, had trouble to generate all requirements within Buildroot (now with gdb+coreutils debugs). I can add glibc debug if needed. > > quotearg_buffer_restyled (buffer=buffer@entry=0x41b5a0 "", > buffersize=, buffersize@entry=256, > arg=arg@entry=0x41c5f0 "folder/test1", argsize=4294967295, > >     quoting_style=, flags=, > quote_these_too=, left_quote=0x0, right_quote=0x0) > at lib/quotearg.c:262 > > (gdb) > quotearg_n_options (n=n@entry=0, arg=arg@entry=0x41c5f0 "folder/test1", > argsize=argsize@entry=4294967295, options=0xbffff630) at > lib/quotearg.c:905 > > 0x00406b46 in copy_reg (src_sb=, > new_dst=, omitted_permissions= out>, dst_mode=, x=, > dst_name=, > >     src_name=) at src/copy.c:1146 > > /bin/cp: setting permissions for 'folder/test1': Value too large for defined data type > > I don't have layout src working but layout asm works. > > (breakpoint at fstatat, then step by step). > > Let me know if you need more details, I'm available for a shared screen visio if needed (I'm in UTC+2). 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 09:22:21 2022 Received: (at 55023-done) by debbugs.gnu.org; 28 Apr 2022 13:22:21 +0000 Received: from localhost ([127.0.0.1]:45775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk469-0004ek-Hi for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:22:21 -0400 Received: from mail-oi1-f178.google.com ([209.85.167.178]:34340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk468-0004eY-0e for 55023-done@debbugs.gnu.org; Thu, 28 Apr 2022 09:22:20 -0400 Received: by mail-oi1-f178.google.com with SMTP id s131so5328536oie.1 for <55023-done@debbugs.gnu.org>; Thu, 28 Apr 2022 06:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=ltMo/TbhbUgzfQ94VFPspigkajTZNvw8uj0eQEdFE3o=; b=LvQJUSNwvx3bvfBoU3tkdd9z+eW8leDy8LT4LlOzFtfcOQzQZ0ZOuvLIlBLSZXhSQS 1+vUZWbjQRG3pv4DA8T5RU96O0EV/bvPlyi9X1XLsqErorCR+qBgSGpq8gNPAaWqPml/ Mgxaureece78Opc9tisE46mEn3MBebBkXB6wOfNDf60MPovD2mDMGOe7Wn13kRVkctmq kp6c87efUCbfBOmFYbJDyJ1agNia9NOOrbPT5SdO2hQHyoljb4SKYAvbbblgT0QNPLhP v0qDANDQ35rvUmPFAaRlzyJdYb9JkXf3di7DR3vzeGM7CqONVKJMblvF3Y4q29+TkXPw 7MUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ltMo/TbhbUgzfQ94VFPspigkajTZNvw8uj0eQEdFE3o=; b=XREeDWLi2EwRlXihq/nYVM3JkbI5brXSInjQZKuoZlKEUjjuYgNDP4Z762WiV6NDAl 1s9cxBCrpFBwtPZR8n7H5SIvEAlIxSX3O4O0Rhix6sYDRs8nAjYerZTeRBgP/DZoKle4 jWvpPnjFdlsgnJ9SPkIp2blaI5ovDdHlmDP6d3v0m7y/zLAtYcLyzR/OU1y19IiofEYD 8ryYQjcd5dxwS7qwHmrpXPufzQz6Ps53kiX5bgyyw1Aq3sBpfQVIVmbepinX06HTYUnP W2Ui114V6BF3rLTeVKqCZfqkHYh5Oeu/PqlqykYsz91rffduvj3OhXNWXgk/VHBrKAEV N6Nw== X-Gm-Message-State: AOAM531UdBVV7Ya+QIwnPQ23cIHqpWxyrfsjzBBiMNdaO+98tSuBeACb J9UdUnBaHMjTJYgYKTd5FNLoAQ== X-Google-Smtp-Source: ABdhPJzOYur+zgOAuKir1JlDs+OntOFQgwLLwD1mB3zeJrJbk2USyVkPpubUZXCSr5mNN8Lw5NWSHQ== X-Received: by 2002:aca:bed6:0:b0:322:bd33:7efc with SMTP id o205-20020acabed6000000b00322bd337efcmr20652704oif.95.1651152134114; Thu, 28 Apr 2022 06:22:14 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:4214:4f75:969e:be61:8b2? ([2804:431:c7ca:4214:4f75:969e:be61:8b2]) by smtp.gmail.com with ESMTPSA id r7-20020a056870878700b000e686d1386csm1855007oam.6.2022.04.28.06.22.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 06:22:13 -0700 (PDT) Message-ID: <42cd1687-a8bd-bac2-eb43-cf41515dfc93@linaro.org> Date: Thu, 28 Apr 2022 10:22:11 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= , =?UTF-8?Q?Arnaud_Pana=c3=afotis?= , 55023-done@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> <473a02d7-0d1d-4dec-8ca2-18fa32a248a9@linaro.org> <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com> From: Adhemerval Zanella In-Reply-To: <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55023-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 19:57:05 2022 Received: (at 55023) by debbugs.gnu.org; 28 Apr 2022 23:57:05 +0000 Received: from localhost ([127.0.0.1]:50323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkE0P-0007Vg-4B for submit@debbugs.gnu.org; Thu, 28 Apr 2022 19:57:05 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkE0N-0007VC-Gz for 55023@debbugs.gnu.org; Thu, 28 Apr 2022 19:57:04 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6AAF6160052; Thu, 28 Apr 2022 16:56:57 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 970Tw118VONW; Thu, 28 Apr 2022 16:56:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B9A6F16005C; Thu, 28 Apr 2022 16:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7dFDIsqlLe9i; Thu, 28 Apr 2022 16:56:56 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 96721160052; Thu, 28 Apr 2022 16:56:56 -0700 (PDT) Message-ID: <98a11b08-8aea-e310-d5d4-684ebfde39ad@cs.ucla.edu> Date: Thu, 28 Apr 2022 16:56:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: 55023@debbugs.gnu.org, P@draigBrady.com, arnaud.panaiotis@gmx.fr References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> <473a02d7-0d1d-4dec-8ca2-18fa32a248a9@linaro.org> <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/27/22 09:42, P=C3=A1draig Brady wrote: > Marking this as done in the coreutils bug tracker, > now that this is being tracked in glibc. This could also be worked around Gnulib for the benefit of 32-bit apps=20 running with unpatched glibc 2.34 and 2.35, or glibc older than 2.34.=20 Not sure it's worth the trouble, though, as the fixed glibc should be=20 universal pretty much everywhere before the year 2038 rolls around. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 29 08:56:33 2022 Received: (at 55023) by debbugs.gnu.org; 29 Apr 2022 12:56:33 +0000 Received: from localhost ([127.0.0.1]:51179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQAj-0000RK-E9 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 08:56:33 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:33789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQAi-0000R6-79 for 55023@debbugs.gnu.org; Fri, 29 Apr 2022 08:56:32 -0400 Received: by mail-wm1-f46.google.com with SMTP id p7-20020a05600c358700b00393e80c59daso5292300wmq.0 for <55023@debbugs.gnu.org>; Fri, 29 Apr 2022 05:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=58u109bUWIqtyvk1y+9ynlFnnPgDW5eCnnAXLJSbFGc=; b=COKfvCPeU0G8L7uzuJfIHsuEksuYGHuuNSDvxKl9iLi9Mks+as7m4EvThOVclCJmot ds/jEsx0yOARMKwfhOFxOwCtKBrEU7FSJBZwssmVhNx7G6L34UVgm25w/lpnbles5Ak2 6J1q1kHQAQ8qfbwQBAmbGDLMxEx5JMBDsAiA3o2AqcX2/8HTEqIoW+sWom1DyDc6sG/7 DXglrd7or405qMaSuOh1gpbJHZMVUddulvh0kX95YBjoaV7nkqJkTuE8J4RrCERbELjr /+t880qpiSYxYYPx+HgsLhi5LShCJ6NI6tCazJE7EorrQi2XE2w9oBDIW0v+IywxuCtS ewmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=58u109bUWIqtyvk1y+9ynlFnnPgDW5eCnnAXLJSbFGc=; b=VKZ5rzi6swtkPcn12dFbMtV3CwGmv1yGGLw5uLppQO/FkpPfr1TuTcoUpLbrbw1/Mh DQ8LSHbD0PpTWPAZrVKC/9wn60FBnotQwDg4GVJmUObNjQjrj5/4QlfOORs/06HxqGcW V+4whdmxIkulCYrn6ZIEqZo+qKdN3vp+OtfFoxEUwY1svzvkrvbcvHbNX+gpdoDRNIyO pn/9gF+lPL1EjeQLacFTwWOLN4HhnW3mbsGAkGEjN/jW+zf42J+L4ISUDLV/CVufDShI meulKnKZ5kTu3ZsZxSlEjLO4qOZ3AC9shWcDAl0uIdn6WR3z6jYAyWUbUazWln6Sfopo v1xw== X-Gm-Message-State: AOAM533eRKpH0Te9O7Hx3wBjp1F3Qw+CyntmmNW25O62WgUgxdpi2A8u eOx9HZ5OA8J0gFrUTgZ/9oQ= X-Google-Smtp-Source: ABdhPJz06XwYQmoXljzovyW/RW6+QG5mzVy9i+zwQhIZnduT1evYchqx8R14u4anCJOVlCWsA4TFjA== X-Received: by 2002:a05:600c:2550:b0:393:fd17:a8d with SMTP id e16-20020a05600c255000b00393fd170a8dmr3095924wma.203.1651236986149; Fri, 29 Apr 2022 05:56:26 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id q1-20020a1c4301000000b00394145534bbsm2705781wma.9.2022.04.29.05.56.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 05:56:25 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2022 13:56:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel Content-Language: en-US To: Paul Eggert , 55023@debbugs.gnu.org References: <49c4a8c0-8e00-5f65-fe55-7ce2f6dae79c@gmx.fr> <5e6094ba-0ded-3497-9b44-1be0e0f2bba2@gmx.fr> <2eaf32db-49ba-e539-d73d-429e8dc2658c@draigBrady.com> <5b034b25-0c69-9843-3862-8f937b810aa6@gmx.fr> <141f1d60-ebaf-00eb-f640-3c003ce009a6@gmx.fr> <5f2cb9fd-78f0-37aa-633d-54a03bfb6ad2@draigBrady.com> <58f2ac6e-8363-d2f5-1282-6646553df183@linaro.org> <9be41665-e497-6e64-4c50-e8c70d82b4fe@gmx.fr> <473a02d7-0d1d-4dec-8ca2-18fa32a248a9@linaro.org> <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com> <98a11b08-8aea-e310-d5d4-684ebfde39ad@cs.ucla.edu> From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: <98a11b08-8aea-e310-d5d4-684ebfde39ad@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55023 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 29/04/2022 00:56, Paul Eggert wrote: > On 4/27/22 09:42, Pádraig Brady wrote: >> Marking this as done in the coreutils bug tracker, >> now that this is being tracked in glibc. > > This could also be worked around Gnulib for the benefit of 32-bit apps > running with unpatched glibc 2.34 and 2.35, or glibc older than 2.34. > Not sure it's worth the trouble, though, as the fixed glibc should be > universal pretty much everywhere before the year 2038 rolls around. Yes I was thinking about that, and also thought it not necessary to deal with in gnulib. thanks, Pádraig. From unknown Thu Aug 14 18:38:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 28 May 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator