Interrupting Paket bootstrapper in "magic mode" can cause future bootstrappers to fail

[rmunn]

Description

If you press Ctrl+C while the Paket bootstrapper is running in "magic mode" and downloading the full paket.exe file, a partially-downloaded file may be left behind. This can result in future runs of the paket.exe bootstrapper failing.

Repro steps

This may or may not work as a reproduction since it probably depends on the timing of when Ctrl+C was pressed, but the way I got this to fail was:

1. Clone the https://github.com/fable-compiler/fable-suave-scaffold repo
2. cp -a fable-suave-scaffold copy-of-scaffold so I'm editing a fresh copy of the repo
3. cd copy-of-scaffold
4. ./build.sh run
5. Hit Ctrl+C after about 5-10 seconds, while Paket is still downloading
6. ./build.sh run again, or run Paket manually with any parameter: mono .paket/paket.exe --help

Result: the following error message in red text.

Input string was not in a correct format. (Github - cached (temporarily ignore updates))

Also, in /tmp there is a file named paket_(long hash).exe, which appears to be a
partially downloaded paket.exe file since its file size is 574036 bytes (link goes to a .zip file because GitHub doesn't allow .exe attachments). Running that file by hand via mono /tmp/paket_(long hash).exe produces the error:

Cannot open assembly '/tmp/paket_(long hash).exe': File does not contain a valid CIL image.

If I delete that truncated /tmp/paket_(long hash).exe file, then re-run mono .paket/paket.exe in the Fable-Suave Scaffold repo (where paket.exe is still the Paket bootstrapper, remember) -- then the behavior changes. First, the /tmp/paket_(long hash).exe file is recreated exactly: same file size, same md5sum. (It's clearly being found in the location where Paket caches its downloaded .exe files, but I don't know where that cache is). Then, I get a segfault from mono, which I've attached as a Gist since it would be annoyingly long to put inline in this issue.

Note that I have not managed to reproduce this when the bootstrapper is running in "non-magic" or normal mode. I.e., when it is named paket.bootstrapper.exe, it succeeds; only when it is named paket.exe have I seen this behavior.

Expected behavior

The bootstrapper should be robust against interrupted downloads, and verify that they do not, in fact, match the proper MD5 / SHA1 / SHA256 sum (as verified by a small text file downloaded from GitHub before starting to download the paket.exe file proper). If the cached file does not have the correct checksum, that paket.exe file should be invalidated from the cache and re-downloaded.

Actual behavior

As described above.

Known workarounds

If I knew where Paket keeps its cache of previouly-downloaded paket.exe files, I could delete the invalid one from the cache. But the cache location doesn't seem to be in any of the places I would find obvious: I looked in $HOME/.paket, $HOME/.cache, and $HOME/.local/share. Perhaps the cache location should be documented on the https://fsprojects.github.io/Paket/bootstrapper.html page.

[matthid]

cache location is appdata/local/nuget/cache/paket iirc

Yes bootstrapper should use a tempfile and only continue if all checks are OK