2nd attempt at fixing progress % >100 on local files with a more or less reasonable degree of accuracy

[Sundownersport]

• For files <4GB, trust the ISIZE value directly.
• For files >4GB, estimate the decompressed size by sampling ~50MB of compressed data and extrapolating the compression ratio, rather than fully decompressing the file upfront. This avoids the I/O cost of a full decompression pre-scan while still providing reasonable progress tracking.
• 50MB should be pretty fast to sample with but is big enough to be accurate.
• This still is not going to be perfect but should MOSTLY resolve user complaints (hopefully it just finishes fast enough if it goes over 100% that they wont even notice).

[tdewey-rpi]

Thanks for the submission, @Sundownersport

It's a good attempt, but you need to be aware of a certain problem:

How do you know if the small ISIZE value is because it's actually small, or because it's so large you've wrapped the 32-bit counter?

Because you can't reliably know that, I went with an indeterminate progress bar and a write counter. You'll see the write counter go 'up', and the progress bar will pulse - but I can't offer a % completion because I just can't trust the container.

Separately, if people are packaging .gz images for you, it might be worth asking them if they wanted to move to XZ or zstd?

[lurch]

50MB should be pretty fast to sample with but is big enough to be accurate.

This also seems to be assuming a uniform compression ratio across the whole file, which for an OS image (which will contain a large variety of file-types) seems pretty unlikely!

[Sundownersport]

Hm yeah i suppose. Honestly it might just make more sense to not show a % progress for files if they done have the file_size data included. just have a GUI element pinging back and forth/spinning etc to show its not frozen