Add download size warning for large files

[Jaifroid]

Description of the new feature/enhancement

I have been testing a manifest for a large install package (~1.2GB), and this has thrown up a couple of one issue:

1. There is no warning to the user about the file size when running winget install ... (in my case, as I am still testing/validating this manifest, I am using the -m switch);
   2. The download of this 1.2GB file, from GitHub repository, was much, much slower (over a fast internet connection) than the equivalent download in a browser. It was painfully slow - 22 minutes (according to the logs) for a 1.2GB file that downloads in the browser in 7 minutes over the same connection (I did a timed comparison). It is also much slower than using the MIcrosoft Store for the same package.

Proposed technical implementation details (optional)

For 1, implement a Large Package Download warning for files in excess of, say, 50MB, with a prompt such as Warning downloading large package XXX GB/MB.... cancel with Ctrl-C (or something similar). This would ensure that the donwload starts and goes ahead if the install is unattended, but a user watching the download is given instructions on how to cancel. I know any script can be cancelled, but a lot of users might not know that. In any case, ideally it wouldn't just be a complete script abort: if the user cancels, it should (ideally) do some cleanup and post a "Cancelled on user request" message to the command prompt. Therefore you might want to use something other than Ctrl-C.

For 2, perhaps #225 could help. Otherwise, I have no explanation for the very slow download.
Other than that, I can report that the download and installation of the package was successful (but unacceptably slow).

EDIT: Item 2 must have been a transient network issue, as another dev has downloaded quickly, and I now corroborate having re-tested. I thnk item 1 above still stands.

[Jaifroid]

The manifest is the one in the linked PR above.

[Jaifroid]

Another dev has tested my 1.2GB package and it downloaded fast for her (5 minutes) via WinGet. I'll monitor this, and post back here if the issue 2 above is resolved or not (maybe I was unlucky).

Regarding issue 1, I do think some large file warning would be useful.

[denelon]

@Jaifroid we don't always know how large the file is ahead of the download. This is particularly challenging with "Vanity URLs". If the installer is swapped out and we aren't informed with an updated manifest, we have no idea how large the file is.

We have attempted using HTTP range request in the past, but we've found a number of hosts with range requests disabled, or set to a static (and incorrect) value. I'll keep this in the backlog to see what we can do, but it might be limited in many cases.

[Jaifroid]

Thanks @denelon. Somehow WinGet seems able to calculate the percentage of the installation that has completed (or does so in the cases I've tested, but these have all been from GitHub repos), so where it knows this (or even where it just thinks it knows this), some kind of filesize warning as above would be useful. If information is kept fom validation of a manifest about the filesize, maybe that could be used. Vanity URLs are a special case, but if we're talking about really big packages, the size change is unlikely to be huge from one package to the next. Anyway, thanks for putting on backlog.

[jharris3299]

@Jaifroid we don't always know how large the file is ahead of the download.

Actually, whoever downloaded and then calculated/submitted the hash of the file does, and if you get the wrong number of bytes, you should also get a hash mismatch.

Perhaps there should be a corresponding filesize field for every SHA-256 hash.

If you look at FreeBSD, we’ve had this for a long time:

https://github.com/freebsd/freebsd-ports/blob/main/security/gnupg/distinfo

Thanks.