rustup has trouble with cygwin

[mcandre]

When rustup is executed from a cygwin-like environment such as Git Bash, then it has trouble with file paths:

$ rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: latest update on 2018-09-13, rust version 1.29.0 (aa3ca1994 2018-09-11)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: removing component 'rustc'
info: removing component 'rust-std'
info: removing component 'cargo'
info: removing component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2018-09-16, rust version 1.30.0-nightly (e4ba1d41e 2018-09-15)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: removing component 'rustc'
info: removing component 'rust-std'
info: removing component 'cargo'
info: removing component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: checking for self-updates
info: downloading self-update

   stable-x86_64-pc-windows-msvc updated - rustc 1.29.0 (aa3ca1994 2018-09-11)
  nightly-x86_64-pc-windows-msvc updated - rustc 1.30.0-nightly (e4ba1d41e 2018-09-15)

error: could not remove 'setup' file: 'C:\Users\vagrant\.cargo\bin/rustup-init.exe'
info: caused by: Access is denied. (os error 5)

[mcandre]

This seems to be fixed for 64-bit Windows but not for 32-bit Windows.

What's more, this problem occurs even when rustup update is run from a PowerShell .PS1 script.

[rbtcollins]

I think this bug is mistitled/analysed - the mismatched path separators don't prevent the msvc runtime (which the windows build of rustup is built with) don't prevent manipulating those files. I think its much more likely that something was holding a file lock open on the rustup-init.exe at the time removal is being attempted.

To analyse this a system tracing tool like process monitor can be used to observe system activity while an update is running and the problem reproduced.

(To verify the path separators can be mixed I wrote a quick test program:

use std::fs::File;
use std::io::Write;

fn main() -> std::io::Result <()> {
    File::create(r"C:\users\USERNAME\.rustup/test").and_then(
        |mut f| f.write_all(b"Hello, world!"))?;
    Ok(())
}

which correctly created the file test in the relevant path.

[rbtcollins]

@mcandre are you able to get a procmon.exe trace of the file activity during an update that fails like this? we should be able to see a stale file handle from something (e.g. mcafee/defender/symantec) holding the file open and racing with the delete. If we can confirm that it is a third party we can add a retry wrapper similar to #1873 for the delete code path too.

[rbtcollins]

This is almost certainly #2441