ER: Compare expected and actual disc image size for discrepancy on ISO selection

[fanfan54old]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
• I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking the "bad blocks" check box in Rufus, and confirmed that my USB is not defective
• I also tried one or more of the following:
  • Using a different USB drive
  • Plugging the USB into a different port
  • Running Rufus on a different computer
• If using an ISO image, I clicked on the # button (at the bottom of the Rufus interface), to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

Hi @pbatard ,
It's the first time I encounter an error in Rufus:
One minute after starting ISO extraction, Rufus stopped copying files, and said that there was an error while extracting files. Only a few files were on the USB drive.
I immediately checked my ISO's size, because I had problems downloading it : the ISO was the problem, ~100Mo instead of 264Mo because Google Chrome gave up waiting for data, and saved an incomplete download.
I think Rufus can avoid these kind of problem, by checking ISO integrity immediately when it's added with the file picker. 7-Zip detected corruptions in my faulty ISO, so maybe you can detect problems without having to compare with the SHA1 hash. Or, you can show the hash in Rufus UI, too, so the user can double-check the ISO integrity before flashing.
Do you think this feature can be useful?

[pbatard]

I think Rufus can avoid these kind of problem, by checking ISO integrity immediately when it's added with the file picker.

The problem is I've seen ISOs that are invalid but that are not detected as invalid by 7-zip. Now, I believe that what 7-zip might be doing is check that the size of the file matches the size of the disc as specified in the ISO header, so I may be able to add such a check. But if it goes further than that, I'm gonna have to pass, because I don't really have the time to explore what 7-zip does, and this is a request that should be addressed to the libcdio project (the library that Rufus uses for pretty much all of it's ISO operations), rather than Rufus. Plus, I don't want to add any costly ISO validation check (i.e. one where the whole ISO would need to be scanned, as this would duplicate the optional checksum validation that users can choose to perform in Rufus, and would therefore be redundant).

Or, you can show the hash in Rufus UI, too

Except, because we reuse libcdio (and reading ISO content is not something that can be expected to be sequential), it is not possible to perform both hashing and extraction at the same time. In other words, if you want extraction and hash, then there is no choice but to read the ISO data twice, in a different way, which of course is very costly in time, and therefore not something you would want to enable by default... in which case, the current optional hash computation, that users can choose to trigger by clicking the # button at the bottom of Rufus is more than good enough (you do know that Rufus already has the ability to compute MD5, SHA-1 and SHA-256 of any image you select, right?)

So, in summary, if there's a way to easily compare expected and real size for ISO9660 and/or UDF images, then, yes, I agree that Rufus could be improved and will try to add that feature.
But if the 7-zip "integrity" check goes further than that, I'm gonna have to pass, unless someone can provide me a patch, and one that would not cost a few more seconds extra time to perform when opening the ISO.

I'm adding this suggestion to the list of 2.16 improvements.

[pbatard]

Okay, I have now added an additional test during ISO selection that checks whether the size of the file on disk is larger than the size of the ISO expected in the header. If that is not the case, you will get this alert:

I believe this should be enough to ward off most of the "incomplete download" issues.
Thanks again for suggesting this improvement!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.