bug-coreutils
[Top][All Lists]
Advanced

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

bug#60455: Missing fallback if copy_file_range returns ENOENT?


From: Sam James
Subject: bug#60455: Missing fallback if copy_file_range returns ENOENT?
Date: Sun, 8 Jan 2023 00:51:55 +0000


> On 7 Jan 2023, at 16:25, Pádraig Brady <P@draigBrady.com> wrote:
> 
> On 07/01/2023 07:34, Sam James wrote:
>>> On 31 Dec 2022, at 18:51, Pádraig Brady <P@draigBrady.com> wrote:
>>> 
>>> On 31/12/2022 17:00, Sam James wrote:
>>>> Hi folks,
>>>> Originally reported in Gentoo at https://bugs.gentoo.org/885793.
>>>> Frank Limpert reported that when copying large files across CIFS shares,
>>>> cp may abort because copy_file_range returns ENOENT sometimes.
>>>> This sounds like a suspicious kernel bug if CIFS interactions are sometimes
>>>> spuriously giving ENOENT, but I'm wondering if coreutils needs to do
>>>> anything to handle this as well.
>>>> strace output from his cp invocation: 
>>>> https://bugs.gentoo.org/attachment.cgi?id=842497
>>> 
>>> We may be able to fallback, but it depends if the errno
>>> is possible to be returned at a partial copy or not.
>>> If partial then there is not much we can do.
>>> Now ENOENT is not a documented errno for copy_file_range()
>>> so I'm not sure what we should do with it.
>>> I didn't see on the bug above if any data was copied.
>>> Could we get more info about that?
>> Frank got back to me and said an empty file gets created:
>> ```
>> # cp /mnt/Backup/EAV/data-eav-eav-aktiv-20221207.dump.xz /mnt/OldBackup/EAV/1
>> cp: error copying '/mnt/Backup/EAV/data-eav-eav-aktiv-20221207.dump.xz' to 
>> '/mnt/OldBackup/EAV/1/data-eav-eav-aktiv-20221207.dump.xz': No such file or 
>> directory
>> # stat /mnt/OldBackup/EAV/1/data-eav-eav-aktiv-20221207.dump.xz
>> File: /mnt/OldBackup/EAV/1/data-eav-eav-aktiv-20221207.dump.xz
>> Size: 0 Blocks: 8 IO Block: 1048576 regular empty file
> 
> OK then it's probably worth handling in coreutils then.
> Note I still get the feeling this is a race in CIFS
> that is only being made more apparent with copy_file_range(),
> but fair enough that this is a regressions for users and
> we should be able to cater for it easy enough.

Total agreement. Thanks, looks good!

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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