Subject: bug#60455: Missing fallback if copy_file_range returns ENOENT?

From: Pádraig Brady <[email-masked]>
Date: Sat, 31 Dec 2022 18:51:12 +0000

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?
Searching for "cifs STATUS_OBJECT_NAME_NOT_FOUND" indicates we
might be able to retry in this case:
https://lists.samba.org/archive/samba/2017-September/211000.html
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.

cheers,
Pádraig