Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The file is successfully copied Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <img width="379" alt="Screen Shot 2020-08-11 at 12 08 34 AM" src="https://user-"<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p<img width="703" alt="Screen Shot 2020-08-11 at 12 10 16 AM" src="https://user-"<img width="638" alt="Screen Shot 2020-08-11 at 12 10 56 AM" src="https://user-"<img width="587" alt="Screen Shot 2020-08-11 at 12 11 59 AM" src="https://user-"</p</detailsApologies for screenshots, I'm running in a VM I can't easily copy/paste out of. See also , which has a likely explanation of the cause of this. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This bug doesn't occur every time, because I think remembers if the system call is available. If is called with two files on the same XFS filesystem, it determines that the system call failed. It then sets a flag to always fall back to a more generic copy method, which prevents the bug from occurring for subsequent calls. <details<summaryCode Example</summary</details
This might be a kernel bug or documentation error because EOPNOTSUPP is not listed in the man page and the kernel even has a warning along with a commit comment that it's the responsibility of the filesystem to perform the fallback. And indeed So that's probably fixed in a newer kernel version, but who knows with redhat's frankenkernels.
If a kernel update doesn't fix it you could also report this to the distro maintainers too, they might have missed something when backporting patches. I haven't looked at the centos kernel sources though, so that's just a guess.
Cc though not sure if you are the right people to ask about the possible kernel issue mentioned above. Regardless we will likely need to handle this ourselves as kernel or distro updates will likely be slow.
Ok, should be easy enough. claim
It only remembers that if it encounters ( or but not ). So it should also try copyfilerange on the second attempt and encounter the same error. Could this be related to automounting? Can you trace the syscalls of your test program via and post the output?
I know that RHEL 7.8 disabled -- see the last note in the : However, I think an from NFS accidentally leaked through, and will be changed to too:
Oh that's a mess, so it returns ENOSYS in most cases but in some cases would still succeed? The detection logic behaves overly pessimistic then, but I guess that's ok if it was broken in older centos versions. I'll treat EOPNOTSUPP like ENOSYS then.
Yes, treating EOPNOTSUPP as ENOSYS here seems like an appropriate workaround for the kernel bug.
I've run strace on the test program I wrote earlier. For two files on an XFS filesystem: On an NFS filesystem:
For some systems (like the one I'm working with), updating is likely not going to happen, and this bug pretty much breaks rustup. I agree with treating as . I still don't know precisely why the kernel bug occurs, but I can't think of a reason why this workaround would be problematic. Future testing for this and related bugs should be done carefully. A simple setup can fail to catch the bug, due to the previously mentioned checks for in .

Discussion:
} let (mut reader, reader_metadata) = open_from(from)?; <del> let len = reader_metadata.len(); </del> <ins> let max_len = u64::MAX; </ins> let (mut writer, _) = open_to_and_set_permissions(to, reader_metadata)?; let has_copy_file_range = HAS_COPY_FILE_RANGE.load(Ordering::Relaxed); let mut written = 0u64; <del> while written < len { </del> <ins> while written < max_len { </ins> let copy_result = if has_copy_file_range { <del> let bytes_to_copy = cmp::min(len - written, usize::MAX as u64) as usize; </del> <ins> let bytes_to_copy = cmp::min(max_len - written, usize::MAX as u64) as usize; </ins> let copy_result = unsafe { // We actually don't have to adjust the offsets, // because copy_file_range adjusts the file offset automatically

}; if let Err(ref copy_err) = copy_result { match copy_err.raw_os_error() { <del> Some(libc::ENOSYS) | Some(libc::EPERM) => { </del> <ins> Some(libc::ENOSYS | libc::EPERM | libc::EOPNOTSUPP) => { </ins> HAS_COPY_FILE_RANGE.store(false, Ordering::Relaxed); } _ => {}

Err(io::Error::from_raw_os_error(libc::ENOSYS)) }; match copy_result { <ins> Ok(0) if written == 0 => { // fallback to work around several kernel bugs where copy_file_range will fail to // copy any bytes and return 0 instead of an error if // - reading virtual files from the proc filesystem which appear to have 0 size //   but are not empty. noted in coreutils to affect kernels at least up to 5.6.19. // - copying from an overlay filesystem in docker. reported to occur on fedora 32. return io::copy(&mut reader, &mut writer); } Ok(0) => return Ok(written), // reached EOF </ins> Ok(ret) => written += ret as u64, Err(err) => { match err.raw_os_error() { <del> Some(os_err) if os_err == libc::ENOSYS || os_err == libc::EXDEV || os_err == libc::EINVAL || os_err == libc::EPERM => { </del> <ins> Some( libc::ENOSYS | libc::EXDEV | libc::EINVAL | libc::EPERM | libc::EOPNOTSUPP, ) => { </ins> // Try fallback io::copy if either: // - Kernel version is < 4.5 (ENOSYS) // - Files are mounted on different fs (EXDEV) <ins> // - copy_file_range is broken in various ways on RHEL/CentOS 7 (EOPNOTSUPP) </ins> // - copy_file_range is disallowed, for example by seccomp (EPERM) // - copy_file_range cannot be used with pipes or device nodes (EINVAL) assert_eq!(written, 0);