Cannot update on Windows due to renaming issues

[qtfkwk]

Problem

Running rustup update on Windows PowerShell and in a Debian WSL to update from 1.74.0 to 1.75.0.

Seeing error messages like:

info: retrying renaming 'C:\Users\qtfkwk\.rustup\tmp\2j4_tc4yey20c_q__dir\bk' to 'C:\Users\qtfkwk\.rustup\toolchains\stable-x86_64-pc-windows-msvc\share/doc/clippy'

It should just update successfully.

Steps

1. Run rustup update on Windows in Windows PowerShell or a Debian WSL.

2. See errors like:

   info: retrying renaming 'C:\Users\qtfkwk\.rustup\tmp\2j4_tc4yey20c_q__dir\bk' to 'C:\Users\qtfkwk\.rustup\toolchains\stable-x86_64-pc-windows-msvc\share/doc/clippy'
   

Possible Solution(s)

Believe the root cause is stupid Windows antivirus / endpoint protection that generally thinks any/all software development is malicious. (Unrelated: I've actually seen an AV not allow the default Rust hello world exe run. Downright lazy if you ask me.) I understand a general need to be proactive, but sheesh, AV products should whitelist all known good executables AND actually scan files for actual malicious behavior. Not sure the issue is specific to just my company's chosen AV / endpoint protection, but just in case it's helpful, it's Trellix.

---

This is stupid, but it worked (for some reason) in both Debian WSL and Windows PowerShell, however in PowerShell, it still printed the same errors except only related to the rust-docs\share/doc/rust/html path.

rustup toolchain uninstall stable
rustup toolchain install stable

Notes

No response

Rustup version

1.26.0

Installed toolchains

Windows PowerShell:

PS C:\Users\qtfkwk> rustup show
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\qtfkwk\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-gnu (default)
stable-x86_64-pc-windows-msvc
active toolchain
----------------
stable-x86_64-pc-windows-gnu (default)
rustc 1.75.0 (82e1608df 2023-12-21)

Debian WSL:

$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/qtfkwk/.rustup
installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (default)
1.65.0-x86_64-unknown-linux-gnu
active toolchain
----------------
stable-x86_64-unknown-linux-gnu (default)
rustc 1.75.0 (82e1608df 2023-12-21)

[djc]

If this is due to overeager AV software, I'm not sure there's all that much that we can do to improve?

Except maybe getting rustup signed by MS? I think that's #242 / #1568.

[qtfkwk]

Agree. MS signing would help I think. Thanks for linking that up! Will check those out. Closing this issue.

In summary, the primary purpose of this issue was to document that the issue still persists and to share that even without resolving the root cause... users might get some relief by trying the following instead of rustup update, which fails and then rolls back.

rustup toolchain uninstall stable
rustup toolchain install stable

[codeabuse]

Bump:

Agree. MS signing would help I think. Thanks for linking that up! Will check those out. Closing this issue.

In summary, the primary purpose of this issue was to document that the issue still persists and to share that even without resolving the root cause... users might get some relief by trying the following instead of rustup update, which fails and then rolls back.

rustup toolchain uninstall stable
rustup toolchain install stable

This does NOT work via VS Code terminal, only directly in the PowerShell.

[rami3l]

Bump:

Agree. MS signing would help I think. Thanks for linking that up! Will check those out. Closing this issue.
In summary, the primary purpose of this issue was to document that the issue still persists and to share that even without resolving the root cause... users might get some relief by trying the following instead of rustup update, which fails and then rolls back.

rustup toolchain uninstall stable
rustup toolchain install stable

This does NOT work via VS Code terminal, only directly in the PowerShell.

Then this might be #988 again. (Sigh...)