`rustup update` needs a cleaner error message if it fails while cleaning files - and no panic

[john-cd]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

rustup update needs a cleaner error message when it fails while cleaning files.

PS C:\Windows\System32> rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: checking for self-update

stable-x86_64-pc-windows-msvc unchanged - rustc 1.91.1 (ed61e7d7e 2025-11-07)

info: cleaning up downloads & tmp directories

thread 'main' panicked at src\utils\mod.rs:479:13:
Unable to clean up C:\Users\XYZ.rustup\tmp: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Steps

run:

rustup update

Possible Solution(s)

No response

Notes

Yesterday the whole internet went done because of a panic (thanks CloudFlare). Maybe we need to remove these unwrap()?

Rustup version

PS C:\Windows\System32> rustup --version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.91.1 (ed61e7d7e 2025-11-07)`

Installed toolchains

installed toolchains
--------------------
stable-x86_64-pc-windows-msvc (active, default)
nightly-x86_64-pc-windows-msvc

active toolchain
----------------
name: stable-x86_64-pc-windows-msvc
active because: it's the default toolchain
installed targets:
  wasm32-unknown-unknown
  x86_64-pc-windows-msvc

OS version

Windows 11

[ChrisDenton]

That's not an unwrap. It's an explicit panic.

rustup/src/utils/mod.rs

Line 438 in 4ae2012

panic!("Unable to clean up {}: {:?}", dir_path.display(), e);

I agree it's not a great error message and we should do better here but it won't substantially change the outcome if a file cannot be deleted. It will still error and exit with a non-zero exit code.

[ChrisDenton]

Well it could be downgraded to a warning in this specific case since cleaning up temp files isn't critical. But I would want to make sure we aren't using this function for more critical places, which may require refactoring.

[djc]

This function (utils::delete_dir_contents_following_links()) is only used in two places:

• From temp::Context::clean(), which is pretty specifically for temporary files
• From rustup_mode::update(), where it's used to clean up the download_dir

[rami3l]

@djc Thanks for the investigation! In that case it might make some sense to treat the error in those circumstances a bit differently?

Reading directly from the source code it seems like a state corruption issue though so I agree that there is nothing to be recovered from when such error occurs.