[Top][All Lists]

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

bug#60455: Missing fallback if copy_file_range returns ENOENT?

From: Pádraig Brady
Subject: bug#60455: Missing fallback if copy_file_range returns ENOENT?
Date: Sat, 31 Dec 2022 18:51:12 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0

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: 

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?
Searching for "cifs STATUS_OBJECT_NAME_NOT_FOUND" indicates we
might be able to retry in this case:
I guess we could be defensive and also fstat(dest_fd)
and fallback to standard copy if no data yet transferred.
However note the above url is suggesting this error may
not be specific to copy_file_range() and just an intermittent cifs thing.
I.e. copy_file_range() is just a red herring here,
and this just needs fixing in the kernel or server side setup.


reply via email to

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