Panic on corrupted downloaded artifact SHOULD NOT happen

[ytain]

Problem

During the rustup update, during the extraction stage, it SHOULD NOT panic on a corrupted downloaded artifact.

I refer to the comment I made in the issue https://github.com/rust-lang/rustup/issues/2166#issuecomment-1165479987

Steps

It's a very difficult process to reproduce, but you have to fix the issue with panicking during extraction of a corrupted downloaded artifact.

Possible Solution(s)

No response

Notes

No response

Rustup version

x86_64-apple-darwin/lib » rustup --version
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.63.0-nightly (43347397f 2022-06-23)`

Installed toolchains

x86_64-apple-darwin/lib » rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/ytain/.rustup

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-2021-12-24-x86_64-apple-darwin
nightly-x86_64-apple-darwin (default)
1.54.0-x86_64-apple-darwin
1.56.0-x86_64-apple-darwin

installed targets for active toolchain
--------------------------------------

aarch64-linux-android
x86_64-apple-darwin

active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.63.0-nightly (43347397f 2022-06-23)

x86_64-apple-darwin/lib »

[rbtcollins]

Without the log of the panic occurring, we cannot even attempt to reproduce it or analyse it.

That said, there are situations where we have to panic, because there is literally nothing we can do that is correct. For instance if the extractiong thread itself fails and the lock gets tainted, all work submitted to the work queue will fail, and we can't shutdown the work queue because we can't fence things because we don't know what state the program actually is in.

If you look in the rustup code you'll find we don't use unsafe or anything clever or exotic - it is boring rust code, making safe boring API calls to the file system.

Whatever is going on the with the file you can't remove after we suffer a panic: it is probable that that fundamental problem is what lead to the panic in the first place, and rustup would also be unable to delete / unlink the file. rustup has no special capabilities over your shell or GUI - if they cannot delete a file, neither can rustup.

[rbtcollins]

I'm not closing this because it is possible that the panic you refer to is one that we could do something better on - but we cannot make any progress on this until you give us enough information to identify it. If you don't have time to get that information for us, thats ok; but in ~a month we will close this because it simply isn't actionable as-is.