Thanks for the PR, @thatguywiththekids!

I think a better route, however, might be to just initialise the flag to false, and then only set it true after we've confirmed we got a meaningful size?

Updated version available now.

The reason for the failed size extraction is also interesting

Indeed - could you make a separate issue for that please, with a link to the relevant archive (if possible)?

The reason for the failed size extraction is also interesting

Indeed - could you make a separate issue for that please, with a link to the relevant archive (if possible)?

The archive is corrupt :/ The checksums differed between Windows and Linux (separate downloads), and after poking KTorrent again on the Linux side I got the rest of the file filled out so the checksums match. Then the only issue is the one addressed in this PR. When I wrote it flashed fine I must have mentally skipped that it flashed fine on Windows specifically and assumed the file was the same, because how could a download be wrong in this day and age (:

Still, percentage should not be displayed in this scenario :)

In light of this, it would be valuable to differ between "this looks broken" and "can't tell how big this really is". What do you think about that? I could try doing something to that end.

In light of this, it would be valuable to differ between "this looks broken" and "can't tell how big this really is". What do you think about that? I could try doing something to that end.

For an uncompressed image we obviously have no way of detecting if it "looks broken"; but for compressed images, I guess maybe we could check if the expected archive header-fields don't appear as they should. Although I guess in practice any "corruption" is statistically far more likely to appear in the "body" of the archive rather than in the very small header at the start of the archive? 🤔
(Even if the archive header contains a checksum (of the decompressed data?) we wouldn't want to verify this checksum before writing the image as a) this would introduce a big delay before writing the image and b) it wouldn't work if we're streaming an image from the internet.)

Yeah, it would catch a pretty specific subset of problems like a prematurely ended xz download. The writing process catches issues eventually, it just takes some time.

Thanks for the updated PR, @thatguywiththekids. This looks like a more ergonomic change - adding more formats in the future becomes somewhat straightforward.