Skip to content

Commit 4ddedd5

Browse files
committed
perform copy_file_range until EOF is reached instead of basing things on file size
This solves several problems - race conditions where a file is truncated while copying from it. if we blindly trusted the file size this would lead to an infinite loop - proc files appearing empty to copy_file_range but not to read/write coreutils/coreutils@4b04a0c - copy_file_range returning 0 for some filesystems (overlay? bind mounts?) inside docker, again leading to an infinite loop
1 parent f078363 commit 4ddedd5

File tree

1 file changed

+12
-3
lines changed
  • library/std/src/sys/unix

1 file changed

+12
-3
lines changed

library/std/src/sys/unix/fs.rs

+12-3
Original file line numberDiff line numberDiff line change
@@ -1140,14 +1140,14 @@ pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
11401140
}
11411141

11421142
let (mut reader, reader_metadata) = open_from(from)?;
1143-
let len = reader_metadata.len();
1143+
let max_len = u64::MAX;
11441144
let (mut writer, _) = open_to_and_set_permissions(to, reader_metadata)?;
11451145

11461146
let has_copy_file_range = HAS_COPY_FILE_RANGE.load(Ordering::Relaxed);
11471147
let mut written = 0u64;
1148-
while written < len {
1148+
while written < max_len {
11491149
let copy_result = if has_copy_file_range {
1150-
let bytes_to_copy = cmp::min(len - written, usize::MAX as u64) as usize;
1150+
let bytes_to_copy = cmp::min(max_len - written, usize::MAX as u64) as usize;
11511151
let copy_result = unsafe {
11521152
// We actually don't have to adjust the offsets,
11531153
// because copy_file_range adjusts the file offset automatically
@@ -1173,6 +1173,15 @@ pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
11731173
Err(io::Error::from_raw_os_error(libc::ENOSYS))
11741174
};
11751175
match copy_result {
1176+
Ok(0) if written == 0 => {
1177+
// fallback to work around several kernel bugs where copy_file_range will fail to
1178+
// copy any bytes and return 0 instead of an error if
1179+
// - reading virtual files from the proc filesystem which appear to have 0 size
1180+
// but are not empty. noted in coreutils to affect kernels at least up to 5.6.19.
1181+
// - copying from an overlay filesystem in docker. reported to occur on fedora 32.
1182+
return io::copy(&mut reader, &mut writer);
1183+
}
1184+
Ok(0) => return Ok(written), // reached EOF
11761185
Ok(ret) => written += ret as u64,
11771186
Err(err) => {
11781187
match err.raw_os_error() {

0 commit comments

Comments
 (0)