Corrupt /missing manifests lead to installation conflicts

[rbtcollins]

The rustup installation system has a transactional system that is only partially transactional.

It isn't concurrent operation safe (see #988 ), but it also isn't able to recover from lost writes to the components file for other reasons such as IO errors or crashes of rustup itself.

These failures show up as conflicts during the next install - e.g.

error: failed to install component: 'rustc-x86_64-apple-darwin', detected conflict: '"lib/rustlib/etc/gdb_load_rust_pretty_printers.py"'

The solution is to remove the entire toolchain and reinstall it with all the desired components. There is no need to uninstall all of rustup, but there is also no lesser solution.

We do not yet have a design for solving this systematically, but see #988 for solving the concurrent-operation safety aspect, which is the most common cause of problems (e.g. for users of IDEs and CI systems that do not serialise their operations internally). We are considering an eventually-consistent model which would address this, but work has not yet started on it.

[jsejcksn]

Adding some additional strings from the console output in order to improve SEO on this issue and help other users discover it:

info: rolling back changes
error: could not rename component file from
update failed

[mark-summerfield]

I had this problem trying to upgrade from 1.58.1 to 1.59.0 on Windows 7-64-bit msvc toolchain inside a VirtualBox. Deleting toolchains didn't work. My solution was to run 'rustup self uninstall' and then manually deleted the .rustup folder (since rustup couldn't do that) and then downloaded rustup-init.exe and that worked fine.

[aminya]

I am having the same issue in GitHub Actions. How does this gets corrupted in a clean system? Is it because of concurrency?