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

Most upvoted comments

@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 rustup error message does not help understanding what the problem actually is. IMHO before attempting to update rustup should 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 update after 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 update worked fine. Thanks all.

For whatever reason: on Windows 10, rustup self update worked when attempted from cmd (via Windows Terminal), but not when attempted from PowerShell (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 of rustup more 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.exe itself. Again, nothing is locking rustup.exe before I run rustup update.

error: could not remove ‘rustup-bin’ file: ‘F:\Cache\Rust\cargo\bin\rustup.exe’: Přístup byl odepřen. (os error 5)