Idea: Add an option to set the mode to fs::copy

zackw:

Linux's copy_file_range also doesn't do the whole job and doesn't work in all cases; callers need to check for a "can't do it this time" error return and fall back to a manual copy loop.

Which it should not yet , because if copy_file_range fails, splice is still likely going to work.

The manual pages don't make it exactly clear what the difference is, but given the limitations mentioned and my understanding of NFS:

• copy_file_range works at the filesystem level. It only works on pairs of regular files on the same filesystem, but it can take advantage of any copy-on-write or snapshot capability of the filesystem, or in case of NFS 4.2 issue the request for the copy to occur fully server-side (well, if it's already implemented; I didn't check that, I only know NFS 4.2 has that function).

• splice (which has the same function signature) works at VFS level. It issues read to the one file and write to the other, just without copying the data to userland and back. That way it works between files, sockets and pipes, and between files across filesystems, but it always copies the data and it always fetches the data and uploads them back in case of a network filesystem.

So the correct approach would really be to try copy_file_range, but then fall back to splice, not a manual copy loop (I don't see a way for splice to fail and manual copy loop still work so that second fallback shouldn't be needed).