Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copying multiple large files results in assertion failed: (left == right) in kernel_copy.rs:592 #91152

Closed
archer884 opened this issue Nov 23, 2021 · 0 comments · Fixed by #91153
Labels
C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@archer884
Copy link

I tried this code:

fn copy_file(path: &Path, target: &str) -> io::Result<()> {
    let mut reader = File::open(path)?;
    let mut writer = File::create(make_target_path(path, target))?;

    io::copy(&mut reader, &mut writer)?;

    Ok(())
}

I expected the copy operation to succeed (that is, to return Ok(())) or to fail (that is, to return Err(BUY A BETTER HARD DRIVE!). What happens instead is a panic thrown from line 592 of kernel_copy.rs. Before I changed from the default mount options to something else, this happened pretty much every time I tried to copy multiple large files from a Linux laptop to a Linux server on my network.

The server in question has a BTRFS volume. That volume was mounted on the laptop by the Gnome shell--er, that is, just whatever Gnome does to mount shares it finds on the network. Because it gets mounted at something obscene, like /this/path/takes/forever/to/type1000/100/volumename, I added a symlink to allow access via ~/share in my home directory. (I only mention this because I already discovered that a symlink renders something like fs::copy unworkable, so.... /shrug)

Anyway, looks like the code in kernel_copy 1) encounters an error, 2) attempts to fall back to user space copy instead of using the fancy kernel copy routine, and 3) panics upon realizing that some data has already been written. I reckon there's some kind of reason for it, but I was still surprised that this is a panic instead of just, "Whoops. We encountered an error."

Meta

rustc --version --verbose:

rustc 1.56.1 (59eed8a2a 2021-11-01)
binary: rustc
commit-hash: 59eed8a2aac0230a8b53e89d4e99d55912ba6b35
commit-date: 2021-11-01
host: x86_64-unknown-linux-gnu
release: 1.56.1
LLVM version: 13.0.0
@archer884 archer884 added the C-bug Category: This is a bug. label Nov 23, 2021
@jyn514 jyn514 added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Nov 23, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 23, 2021
…the8472

kernel_copy: avoid panic on unexpected OS error

According to documentation, the listed errnos should only occur
if the `copy_file_range` call cannot be made at all, so the
assert be correct.  However, since in practice file system
drivers (incl. FUSE etc.) can return any errno they want, we
should not panic here.

Fixes rust-lang#91152
@bors bors closed this as completed in b490ccc Nov 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants