-
Notifications
You must be signed in to change notification settings - Fork 892
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
Fix #1870: Race condition with some virus scanners #1873
Conversation
Some virus scanners take out handles on files we are going to rename, causing access errors and preventing the rename. Typically this is short lived. Retry rather than erroring. No feedback given at the moment, and it will be a much larger patch to do so - as this is a regression fix I'd like to get it in and released and follow up with something thread all the UI channels down to this layer later (e.g. an implicit context mechanism of some sort perhaps?)
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.
Looks sound, thank you for doing the work with the retry
crate too.
One point to address
This will happen to wsl v1 users on windows too as they share a file system.
…On Sun, 26 May 2019, 07:24 Daniel Silverstone, ***@***.***> wrote:
***@***.**** requested changes on this pull request.
Looks sound, thank you for doing the work with the retry crate too.
One point to address
------------------------------
In src/utils/utils.rs
<#1873 (comment)>:
> @@ -651,7 +654,21 @@ pub fn toolchain_sort<T: AsRef<str>>(v: &mut Vec<T>) {
}
fn rename(name: &'static str, src: &Path, dest: &Path) -> Result<()> {
- fs::rename(src, dest).chain_err(|| ErrorKind::RenamingFile {
+ // #1870
+ // 21 fib steps from 1 sums to ~28 seconds, hopefully more than enough
+ // for our previous poor performance that avoided the race condition with
+ // McAfee and Norton.
+ retry(
+ Fibonacci::from_millis(1).map(jitter).take(21),
+ || match fs::rename(src, dest) {
+ Ok(v) => OperationResult::Ok(v),
+ Err(e) => match e.kind() {
+ io::ErrorKind::PermissionDenied => OperationResult::Retry(e),
I suppose, on a Linux system (or mac) where the EPERM was actually more
to do with someone chown()ing their stuff oddly, this will end up
consuming 28s before failing -- should we fail faster by making this
somehow conditional on Windows?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1873>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADZ7XW3FT4EH7OVHVW7EJTPXGG77ANCNFSM4HPTWVRA>
.
|
Accepted. |
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.
If we get a green CI, this LGTM.
I think the appveyor failure is spurious. |
Some virus scanners take out handles on files we are going to
rename, causing access errors and preventing the rename. Typically
this is short lived. Retry rather than erroring.
No feedback given at the moment, and depends on an unreleased
retry, so WIP...