-
Notifications
You must be signed in to change notification settings - Fork 654
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
Adds implementation of copy_file_range() #1008
Conversation
This fixes #941 |
This doesn't even compile. Did you forget to commit something? |
6ea89a9
to
b9facc2
Compare
Forgot to commit something. Rebased the commit with the changes. Am a bit new to the multi-arch setup and accidently removed the import for the darwin target. |
b9facc2
to
53c7982
Compare
src/fcntl.rs
Outdated
/// On completion the number of bytes actually copied will be returned. | ||
#[cfg(any(target_os = "android", target_os = "linux"))] | ||
pub fn copy_file_range( | ||
fd_in: RawFd, off_in: Option<&mut libc::loff_t>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are the offsets provided as mutable references? If this operation changes them, could you describe how in the doc comment?
Also, it's ugly to expose raw libc types in our public API. In this case, I think it would be preferable for the arguments to be &mut i64
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree completely. I'll fix it to the &mut i64
and add some docs. Still wondering how far to stretch this. Wouldn't it be nicer to return a struct with the new state?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Returning a struct would be more Rusty than using mutable arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it would be a bit of an overkill and possibly also a memory management issue to return new structs. Purpose of this method is to quickly copy large parts of files incrementally, so it will most likely be called in an iterative fashion with feedback. Agree to leave it the way it is now, or do we want some extra helper methods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it would be ok to leave as is. Returning a structure with offsets could be up to 256 bits.
let off_out = off_out.map(|offset| offset as *mut _).unwrap_or(ptr::null_mut()); | ||
|
||
let ret = unsafe { | ||
libc::syscall(libc::SYS_copy_file_range, fd_in, off_in, fd_out, off_out, len, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the last argument be flags
instead of 0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done (flags removed)
test/test_fcntl.rs
Outdated
tmp2.as_raw_fd(), None, | ||
3, CopyFileRangeFlags::NONE).unwrap(); | ||
|
||
tmp2.sync_all().unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I the sync_all
necessary? I would think that the test should work fine without it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently not. I was trying to be overly cautious.
src/fcntl.rs
Outdated
fd_in: RawFd, off_in: Option<&mut libc::loff_t>, | ||
fd_out: RawFd, off_out: Option<&mut libc::loff_t>, | ||
len: usize, | ||
_flags: CopyFileRangeFlags) -> Result<usize> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I must admit I'm not enthusiastic about the flags
argument. It currently provides no benefit to the user, and there's no guarantee that Linux will ever use it. But it does require a lot of typing. Maybe we should omit it. Or we could at least reduce the typing by changing the type to Into<CopyFileRangeFlags>
so the user can simply supply 0
. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Linux probably has it to provide forward compatibility. I'm ok with omitting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the flags.
53c7982
to
d0506a2
Compare
The tests are failing because Travis's Linux kernel is too old. We could switch Linux testing from Travis to Cirrus, but I don't want to hold up this PR just for that. Why don't you just add an |
a69d686
to
5872fc0
Compare
Also adds CHANGELOG.md and tests
5872fc0
to
44277be
Compare
/// Linux version is too old for `copy_file_range`. Should work | ||
/// on netbsd build. | ||
#[test] | ||
#[cfg_attr(target_env = "linux", ignore)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Linux is a target_os, not a target_env. Also, you should leave a message with the ignore attribute. And it's not going to work on a "netbsd build", because NetBSD doesn't have this syscall at all. Finally, we use Travis, not Jenkins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anything else that is holding this PR back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The OP needs to address my last comments, fix the CI failures, and rebase.
This PR can be closed, right? |
Yeah, since it was replaced by #1069 this PR can be closed. |
Also adds CHANGELOG.md and tests