rustup: rustup self update fails on Windows "error: could not remove 'rustup-bin' file: 'C:\Users\USER\.cargo\bin\rustup.exe'"
Running rustup self update on Windows is failing because it can’t delete it’s own binary.
USER@MACHINE MINGW64 /c/dev
$ rustup self update
info: checking for self-updates
info: downloading self-update
info: rustup updated successfully to 1.11.0
error: could not remove 'rustup-bin' file: 'C:\Users\USER\.cargo\bin\rustup.exe'
info: caused by: Zugriff verweigert (os error 5)
info: backtrace:
stack backtrace:
0: 0x7cab64 - <no info>
1: 0x61007b - <no info>
2: 0x503f6f - <no info>
3: 0x42f073 - <no info>
4: 0x43b62f - <no info>
5: 0x43a095 - <no info>
6: 0x8c950b - <no info>
7: 0x8c5f2a - <no info>
8: 0x43ed8c - <no info>
9: 0x4013e3 - <no info>
10: 0x7561343d - BaseThreadInitThunk
11: 0x77659832 - RtlInitializeExceptionChain
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 11
- Comments: 24 (7 by maintainers)
Commits related to this issue
- Merge pull request #1813 from jasonwilliams/master fixing formatting helps with #1367 — committed to rust-lang/rustup by kinnison 5 years ago
@piscisaureus rustup already does this renaming itself, and this functionality is extensively tested - this error means that something else is holding a lock on rustup.exe, hence insufficient detail. Most likely reason is that the RLS is running in the background.
I confirm the issue on Windows 7 with RLS running (VSCode open). The solution is to stop RLS (by closing VSCode). The
rustuperror message does not help understanding what the problem actually is. IMHO before attempting to updaterustupshould verify if any process is running, and in this case emit an understandable message.Leaving this in case anyone bumped into the same issue.
@Diggsey’s explanation is spot on. I can’t seemed to update rustup tonight, and after reading, I realized that RLS is running in the background (atom).
Closed atom and it updates cleanly now.
I have the same issue, probably RLS running in background but I don’t know why rustup doesn’t busy wait and tell that it can’t remove the file. Now that everything else has been updated I am not really sure it’s safe to use rustup since it left the system in inconsistent state where the rust itself has been updated but rustup is presumably not?
Update: seems like running
rustup self updateafter closing VSCode did the trick and everything seems to be fine. So maybe it’s not that bad after all 😃I also received the same error. Upon closing VSCode (which had RLS running), re-running
rustup updateworked fine. Thanks all.For whatever reason: on Windows 10,
rustup self updateworked when attempted fromcmd(via Windows Terminal), but not when attempted fromPowerShell(also via Windows Terminal).Most of the installers on Windows seem to use the Restart Manager API. The Microsoft documentation contains some description and example code for using the API.
Note that the API can just be used to detect which process holds a lock on some file (similar to
lsof) and make the error message ofrustupmore helpful to users. It is not necessary to actually “restart” the other processes holding the lock.Is it possible to include in the error message something helpful or even better, an automatic fix, as this is an issue anyone trying to run rustup update in vs code is likely to experience.
Running into this again. This time, it’s failing to update
rustup.exeitself. Again, nothing is lockingrustup.exebefore I runrustup update.