CRC check all .bin files?

[Edgar Gilbert]

Does inno setup do a CRC check of all .bin files during a disk-spanning installation? I am planning to create a large install package with more than 100 .bin files, and I'm wondering if I need to provide some external means of verifying the .bin files. A few years ago I distributed an install with a few dozen .bin files, and one user reported that one of his downloaded .bin files was apparently corrupted because it consistently extracted a corrupted application file, but inno setup did not give him any error messages during the install. I was not able to verify his claim, but I would I would like to be assured that a corrupted .bin file will always be detected during an install.

[Jordan Russell]

Yes, unless you specify the "dontverifychecksum" flag, all extracted
files are hash-checked, regardless of the DiskSpanning setting. In the
event of a hash mismatch, an error message is displayed with
retry/ignore/cancel options. Also, file metadata stored in setup.exe
(e.g. names, sizes, hashes, and times) is CRC-checked.

However, note that by default Setup will not replace an existing EXE/DLL
file if the existing file's version number is not lower than the
installer's version of the file. So, by default, if an existing EXE/DLL
file is corrupted, simply re-running the same installer (without
uninstalling first) may not repair it. To ensure that same-version files
are replaced, use the "ignoreversion" flag or the "replacesameversion"
flag. "ignoreversion" is the stronger of the two (it replaces files
unconditionally), but should only be used on files private to your
application (not on shared DLLs).

-JR

[Edgar Gilbert]

Thank you JR.

I ran some experiments and now I see that I didn't state the problem exactly right. I changed a byte in one of the .bin files and ran the setup. Inno setup detects that a file is corrupted and tells you the name of the file that it was trying to install, but it does not tell you the name of the .bin file that it was reading when the error occurred. In a large installation that has more than 100 .bin files, the user has no idea which one is corrupted. If these are downloaded from a file server, the user would have to download hundreds of GBs of data to correct the problem instead of just a single .bin file.

-- Ed

 

[Jordan Russell]

On 1/28/25 7:50 AM, Edgar Gilbert wrote:
> Inno setup detects that a file is corrupted and tells you the name of the
> file that it was trying to install, but it does not tell you the name of
> the .bin file that it was reading when the error occurred. In a large
> installation that has more than 100 .bin files, the user has no idea which
> one is corrupted.

A file can span multiple slices, though. When a file is found to have
the wrong hash after extraction, Setup doesn't know where within the
compressed stream the corruption is located, and thus can't reliably
report which slice is corrupted. And if solid compression is enabled,
Setup doesn't know which slices contain each file, because by default
all files are compressed into a single stream that spans all slices.

Also, decompression algorithms may buffer large amounts of input in
advance. Slice 2 might be the most recently accessed slice on disk, but
the corrupted file could have come from slice 1 content that was
buffered earlier.

In order to know which slices are corrupted, there would need to be hash
checks of the slices themselves (i.e., pre-decompression), not just hash
checks of the extracted files (post-decompression). This is something
I've considered, but it probably won't happen in the near future.

Actually, Setup does know when a slice file is the wrong size (e.g., an
incomplete download), so in that specific case it could display a
filename. That may be the most common form of "corruption". Files
downloaded over HTTPS already get checksummed in transit, so seeing bit
flips within the slice files should be extremely rare (unless there's a
hardware problem).

-JR