rustup self update fails on Windows "error: could not remove 'rustup-bin' file: 'C:\Users\USER\.cargo\bin\rustup.exe'"

[peddermaster2]

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

[piscisaureus]

I don't understand why this is labeled "insufficient detail".
On windows a file that is being executed can't be overwritten. It may work to rename rustup.exe to something else first, then write the new file.

[piscisaureus]

For people that are having this issue, here's how I worked around it:

cd "%USERPROFILE%\.cargo\bin"
ren rustup.exe rustup1.exe
mklink rustup.exe rustup1.exe
rustup update
del rustup1.exe

[Diggsey]

@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.

[SeiryuZ]

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.

[pronebird]

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 :)

[lucatrv]

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.

[mkduer]

I also received the same error. Upon closing VSCode (which had RLS running), re-running rustup update worked fine. Thanks all.

[MalteSchledjewski]

I do have a similar problem.
I have a gitlab runner on my machine.
I set up a new user "gitlab".
Running a CMD as "gitlab" I installed rustup.

Now whenever there is a rustup self-update, I get the following error:

$ rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-gnu'
info: checking for self-updates
info: downloading self-update

  stable-x86_64-pc-windows-gnu unchanged - rustc 1.34.1 (fc50f328b 2019-04-24)

$ rustc --version && cargo --version
error: could not remove 'rustup-bin' file: 'C:\Users\gitlab\.cargo\bin\rustup.exe'
info: caused by: Zugriff verweigert (os error 5)
error: could not remove 'setup' file: 'C:\Users\gitlab\.cargo\bin/rustup-init.exe'
info: caused by: Zugriff verweigert (os error 5)

If I then manually start a CMD as "gitlab" and do the same steps, everything works.

So far I haven't found a solution.

I do not have concurrent builds so there should be no additional lock on any file.
My only guess is, that gitlab-runner does mess with the permissions.

[twhiteheadzm]

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.

[danielsilverstone-ct]

There isn't a lot we can do to fix it without introducing other issues instead due to the limitations in Windows. It's possible we could construct a more informative error context though.

[t-rapp]

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.

[kinnison]

That is very interesting, thank you @t-rapp

[Perregrinne]

Closing out of all instances of VS Code and even running Command Prompt as Administrator did not help, but rebooting the computer and rerunning the command did (I did not need to run Command Prompt as Administrator after rebooting).

[kinnison]

I imagine this means that at least one rustup instance was still present, perhaps as a background process. I'm not certain how to tackle this on Windows safely :(

[rbtcollins]

#2441 is the systemic bug for these sort of errors.

[t-rapp]

@kinnison: Although this issue has been closed I'd like to get rid of some RestartManager API example code that I just ported to Rust, for future reference.

[rbtcollins]

I've now looked into it and I don't think RestartManager is suitable for the problem for rustup. It doesn't handle the case of new processes starting up during the update procedure. And it depends on throwing up UI prompts for shutting down and restarting things. It's a fine solution for the general case but we can do better in the special case.

[chylex]

I'm getting the same error, except there is nothing rust-related running apart from rustup update. I can delete the whole bin directory manually without issues, which would not be possible if something else was holding onto any of the files. What worked for me was deleting everything in bin except for rustup.exe, then rustup update recreated all the exes and finished without errors.

[mpetricone]

This was due MS Visual Studio Code locking the %USERPROFILE%/.cargo directory for me. I have a few seemingly common rust extensions enabled. Quitting Code released the file locks.

[SpaceMonkeyForever]

had this issue because intellij was locking rustup

[chylex]

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)

[chylex]

It keeps happening and my original workaround doesn't work.

1. I tried renaming rustup.exe but I'm getting unknown proxy name: 'rustup2'
2. I tried moving it into another directory, which I can do because it's not being used by anything, but then I'm getting rustup is not installed at ...
3. The mklink workaround gives me could not create link from rustup.exe to rustfmt.exe
4. Downloading rust again gives me a warning that I already have an existing installation.

What am I supposed to do?

[worstpractice]

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).

[djc]

@ChrisDenton can you reproduce this?

[worstpractice]

For clarification, the workaround I found only works when cmd is launched directly (like so):

In other words, starting the Windows Terminal normally (which defaults to PowerShell on my machine) and only then launching cmd (from within PowerShell) does not prevent the bug from occuring. ❌

However, directly starting cmd (as shown in the above screenshot) does successfully prevent the bug from occuring (atleast on my machine™). ✅

A wild guess: it might be related to permissions differences (e.g. user account-level installation vs system-wide installation) between PowerShell and/or cmd and/or rustup. 🤷‍♂️