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.