On Sun, 27 Sep 2020 14:35:39 +0100, Ralph Corderoy wrote: > > Otherwise, you can verify the physical disc in the same way you > > would verify the ISO file. > > True, though I think I recall, back when CD and DVD burning was > common, you had to be careful the block device didn't return a few > more bytes than were in the ISO, e.g. the ISO was an odd number of > KiB and the block device added 1 KiB of zero bytes when reading it > back to make a whole 2 KiB block. Perhaps that wasn't with an ISO > but something else. Anyway, the point remains: if the digests > differ then the number of bytes consumed is of interest.
A rather good point. I must have got lucky with the number of bytes, unless the behaviour of the block device has changed. Whoops! > When both are to hand then cmp(1) has the advantage of stopping as > soon as they deviate, rather than reading both to the end, and > indicating how far in that is for further investigation. I went for sha256sum because that's what you would have to use to compare against Mint 20's published checksums, but you are quite right that there is no point in calculating a digest if you are comparing the physical disc against a known-good ISO file. (And, for the example, I did have an ISO file.) I would normally have reached for diff(1) for a direct comparision between two files, out of familiarity. (When all you have is a hammer, etc.) But cmp(1) (new to me) is clearly a better tool for this job. cmp also solves the extra-bytes problem, because it will tell you "EOF on whatever.iso" if the physical disc is identical to the ISO except for having padding at the end. (Not to be confused with "EOF on /dev/cdrom", which would mean the physical disc was incomplete.) Thanks for cluing me in to b2sum. (I don't have it here, but it will probably come with my next OS upgrade.) Patrick -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
