Skip to content
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

self update fails on windows (access is denied) #1869

Closed
doxxx opened this issue May 23, 2019 · 8 comments
Closed

self update fails on windows (access is denied) #1869

doxxx opened this issue May 23, 2019 · 8 comments
Labels

Comments

@doxxx
Copy link

doxxx commented May 23, 2019

Problem
rustup self update fails with an access denied error on Windows 10 with Cisco AMP for Endpoints installed.

Output:

C:\Users\gordon.tyler> rustup self update
info: checking for self-updates
info: downloading self-update
info: rustup updated successfully to 1.18.3

error: could not copy file from 'C:\Users\gordon.tyler\.cargo\bin\rustup-init.exe' to 'C:\Users\gordon.tyler\.cargo\bin\rustup.exe'
info: caused by: Access is denied. (os error 5)

Possible Solution(s)
Cisco AMP does some funky stuff with file deletions, especially executables. I've personally experienced the following sequence of events:

  1. Delete a file in Windows Explorer
  2. See the file disappear from the window
  3. Hit F5 to refresh and the file re-appears
  4. Hit F5 to refresh again a few seconds later and the file disappears again.

My theory is that Cisco AMP interferes in the file deletion code path, returns a success code to the caller but doesn't actually delete the file until it has finished scanning it.

It's possible that if rustup self update is attempting to delete the old rustup.exe and immediately copy in a replacement, then Cisco AMP is interfering. Retrying a few times over a few seconds may workaround this.

Notes

Output of rustup --version:

rustup 1.18.3 (435397f48 2019-05-22)

(this is the version I was updating to)

Output of rustup show:

Default host: x86_64-pc-windows-msvc

stable-x86_64-pc-windows-msvc (default)
rustc 1.33.0 (2aa4c46cf 2019-02-28)
@doxxx doxxx added the bug label May 23, 2019
@eddyp
Copy link

eddyp commented May 23, 2019

I'm seeing the issue on regular update (NOT self) on Windows 10 without any Cisco AMP.

C:>rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: checking for self-updates
info: downloading self-update

stable-x86_64-pc-windows-msvc unchanged - rustc 1.34.2 (6c2484dc3 2019-05-13)
nightly-x86_64-pc-windows-msvc unchanged - rustc 1.36.0-nightly (37ff5d388 2019-05-22)

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

rustup --version says:

rustup 1.18.2 (a0bf3c9cb 2019-05-02)

rustup show says:

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc

installed targets for active toolchain
--------------------------------------

thumbv7em-none-eabi
x86_64-pc-windows-msvc

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.34.2 (6c2484dc3 2019-05-13)

@kinnison
Copy link
Contributor

I'm seeing the issue on regular update (NOT self) on Windows 10 without any Cisco AMP.

We do a self-update at the end of any update anyway. So that's the same codepath.

This error could also easily be that we've a proxy still running or somesuch.

I'm considering a rename() based approach to try and mitigate this kind of issue. See #1865

@doxxx
Copy link
Author

doxxx commented May 24, 2019

@eddyp I consider your case to be a little different: yours is failing to remove the old rustup.exe before copying in the new one, whereas mine appears to "successfully" remove the old rustup.exe but then fails to copy in the new one.

@kinnison I can try testing your fix to see if it works with Cisco AMP. My concern is that it will suffer from the same problem, regardless of whether you're copying or renaming, since the underlying problem is that the destination file still exists even though the OS reported it as successfully removed.

@kinnison
Copy link
Contributor

We're hoping that #1873 might resolve this at least a bit.

@rbtcollins
Copy link
Contributor

Hmm, I doubt 1873 will resolve this, but yeah will it interact - it will certainly permit folk time to close IDE's or have compiles exit before it errors.

@doxx can you please use process monitor or WPA or similar to get a trace of handle activity on the files in C:\Users\gordon.tyler\.cargo\bin so we can verify if it a slow/rogue proxy (and thus #1873) or Cisco AMP - and if it is AMP, please give us a trace of what its doing so we can design a workaround.

@doxxx
Copy link
Author

doxxx commented May 27, 2019

@rbtcollins Here's a Process Monitor dump of all the file access to the .cargo\bin folder during a rustup self update from v1.17.0 to the latest.

ZIP includes PML and CSV formats of the same data:
rustup-self-update.zip

@doxxx
Copy link
Author

doxxx commented May 27, 2019

The sfc.exe process is Cisco AMP.

@rbtcollins
Copy link
Contributor

rbtcollins commented Jul 27, 2020

I'm closing this in favour of #2441; I think the retries proposed in it will solve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants