sync: handle fcntl errors with localized warnings #10330
Conversation
CodSpeed Performance ReportMerging this PR will improve performance by 3.32%Comparing Summary
Performance Changes
Footnotes
|
| /// Logs a warning if fcntl fails but doesn't abort the operation. | ||
| #[cfg(any(target_os = "linux", target_os = "android"))] | ||
| fn open_and_reset_nonblock(path: &str) -> UResult<File> { | ||
| let f = File::open(path).map_err_context(|| path.to_string())?; |
There was a problem hiding this comment.
Theres a bunch of issues with the current implementation, but it depends what is in scope for this PR?
The File::open
You can replicate this with:
mkfifo /tmp/testfifo
timeout 2 sync --data /tmp/testfifo
GNU will fail immediately and uutils with timeout
There was a problem hiding this comment.
I implemented a fix for this here: https://github.com/uutils/coreutils/blob/main/src/uu/tail/src/tail.rs#L224 maybe we should make it a shared library and reuse it here
| let f = File::open(&path).map_err_context(|| path.clone())?; | ||
| // Reset O_NONBLOCK flag if it was set (matches GNU behavior) | ||
| let _ = fcntl(&f, FcntlArg::F_SETFL(OFlag::empty())); | ||
| let f = open_and_reset_nonblock(&path)?; |
There was a problem hiding this comment.
The other issue is that GNU goes through all inputs and sets the error code to 0 if any fail, but here it exits after the first one.
For when bad1 and bad2 do not exist:
sync --data bad1 bad2
GNU shows:
sync: error opening 'bad1': No such file or directory
sync: error opening 'bad2': No such file or directory
And uutils only has:
sync: error opening 'bad1': No such file or directory
There was a problem hiding this comment.
Probably want to make an integ test for both of the usecases that are not matching
|
@sylvestre how would you feel if we just merge these as is and follow up with the GNU deviations in follow up PR's? Each of these issues exist beforehand. Then even when adding integ tests for those two scenarios the PR's will be easier to review and merge? Similar to this one where the PR fixes deviations and is correct its just that there's additional things to fix, #10300 but would be easier to address them in follow ups with smaller scope |
No description provided.