Before 1.97.1 was announced I got nervous sniffing for it on bug reports. So I did rustup update and cancelled it when it was still downloading 1.97.0.
Surprise: the safety conscious language Rust had very unatomically shot itself in the foot. How can it first destroy the old and then see if a download of the new succeeds? What if my internet connection or the server crashes? I’d be left without the Rust of my Life for an indeterminate duration!
On a space constrained system this might be an attractive option. But it shouldn’t be the default behaviour.
Plus
Not only that, but since some versions, both for stable and nightly on Linux, towards the end I’m being hit with the old unsolved
error: could not rename 'component' file from '/home/pfeiffer/.rustup/tmp/li4zgz9t_3isgdyc_dir/bk' to '/home/pfeiffer/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/etc': Directory not empty (os error 39)
Here it might be more difficult to reinstate the old working version. At least it could guide me to uninstall and reuse the already downloaded stuff.
Rustup does not delete the old toolchain until the new toolchain has replaced it. In fact it has a whole "transaction" system to ensure that if something goes wrong it returns everything to the state it was. E.g. within this system, removing files and directories just renames (and on failure they're renamed back).
It sounds like you're hitting a concurrency bug caused by two or more instances of rustup running while at least one of them modifies the installed toolchains (e.g. if you have an IDE running). This can cause its state to become corrupted. This is a long standing issue that requires a new locking mechanism be implemented (work is in progress but rustup maintainers tend to be short on available time).
I would suggest people disable auto-install to lessen the impact of this.
Edit: Wow, just after finishing this, I saw rustup v1.29.1, which (partly?) solves the concurrency problem.
The logging (since scrolled away) had several messages about removing this and that, before getting to the download.
Yes rust-analyzer was on, but I hadn’t touched the IDE. So it should have been inactive. I wasn’t aware that it does more than cargo check.
There is this, which may have woken up as soon as the toolchain was touched. (I don’t like this file anyway, as I find it rather intrusive. We even had the Rust version in the past, which wasted a lot of disk space, by installing a duplicate under the version name, instead of (sym-)linking as much as possible.)
