You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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."
…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.
Fixesrust-lang#91152
I tried this code:
I expected the copy operation to succeed (that is, to return
Ok(())
) or to fail (that is, to returnErr(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 likefs::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
:The text was updated successfully, but these errors were encountered: