pbatard
commented
2 years ago Well, for one thing, you have to understand that when Rufus writes an ISO to USB, its default mode is not to do a block byte block copy (i.e. DD writing) of the data (because that's only possible for ISOHybrids, which precludes all Windows ISOs, since these are not ISOHybrids, and also because, despite what many Linux folks advocate, DD writing is not always for the best) but a file by file copy. This means that you can't usually just compare the checksum of the original image with what Rufus has written.
So what you request would only ever be possible for when writing an image in DD mode, which considerably reduces the field where it can be applied.
But even then, and even if the data is written without any errors, one of the issues we face is that is the ISOHybrid contains an ESP, which most modern Linux ISOHybrids do, then chances are that, the minute it gets written to a USB drive, Windows will create a System Volume Information folder along with a couple of files within the ESP, thereby ensuring that the MD5/SHA1/SHA256 no longer matches, since this content will be created in lieu of free space that was present on the original ISO. Thus, even as mitigate against the creation of System Volume Information on ESPs, (like Etcher does, which I know provides write check, but only because it can only ever write data in block by block mode — hence the reason why Etcher does not support Windows ISOs), but it's difficult to guarantee that, even if the image was written perfectly, the checksums will always match. For instance, to make the feature a bit more useful, so that someone can try to validate a drive after they have taken it out, tried it, and suspect its data might have been corrupted, it'd be nice if you could re-plug a drive, select an image, and have Rufus tell you if the drive content and the image match. But the minute you replug a drive with an ESP on Windows, System Volume Information will be created, which makes the use of a checksum useless.
Finally, there are all the alternative modes that Rufus can use to create a drive (Windows To Go, FreeDOS, etc..) that make it very difficult to validate the written data.
Now, that doesn't mean I don't have long term plans to add image content validation after it's been written to disk, but that'll need individual file validation in order to be useful, which makes things a lot more complex if we want to do a thorough job of validating everything that was written by Rufus (because then we also have to check bootloaders and other non trivial data that may not have come from a file that resides on the ISO).
So, for the time being, I just have to close this issue, bearing in mind that I am not rejecting the feature request, because, again, I do have long term plans to add validation in some shape of form, but because I just don't know when I'm going to do this (it'll probably be years before that happens) and it'll take more than validatin an image checksum to provide something that I can present to users.
KnightKRIT
github-actions[bot]
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button 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
<Hello. This is a request, not issue submit. Is possible to add a function to check the content from the key USB, after "burn" complete, is equals to ISO burned? Thank You.>
Log