On 2009-03-31_09:53:51, Matus UHLAR - fantomas wrote: > > >On Sun,29.Mar.09, 20:28:44, Angelin Lalev wrote: > > >> Is there a way to check a written DVD against the checksum of the iso > > >> image written on it? > > > In <20090329202842.ga3...@think.homelan>, Andrei Popescu wrote: > > >$ md5sum /dev/dvd > > > > > >This should result in *exactly* the same checksum as the iso > > On 29.03.09 16:27, Boyd Stephen Smith Jr. wrote: > > Not in my experience. Both DVDs and CDs have a physical sector size. If > > the > > image is not a multiple of that sector size, the md5sum of the block device > > and the image will differ, because of the extra bits in the last physical > > sector. > > afaik, if the same image is written to multiple CDs/DVDs, they all should > have the same md5sum, independently on its size. That is the one md5sum > shjould report. The same for sha1sum.
Are you saying that two files that have different lengths (size) should have the same md5 or sha1? If you mean something else by size, ignore this post, but ... The design goal of both md5 and sha1 is to provide, for any file, a message digest that is different from that of any other file that is different from the first file in any way. If the file that is read from CD/DVD device is longer, or shorter, than the iso that was used to burn the CD/DVD then the two files are different in a way that is significant to the message digest idea. For two files to have the same message digest, they must be bit for bit identical. That means, at a very minimum, they must have the same length. The motivation for the invention of sha1 was that there was growing evidence that md5 was failing to meet the design goal of "identical message digest only if the files are identical". IOW, a message digest algorithm must NOT ignore trailing zero bytes, or trailing "garbage" bytes that have no effect on the meaning of the file in its intended use. Trailing zero bytes are easy to truncate. If the truncate file has a matching message digest, one can be reasonably confident that the file with the trailing zeros will function properly. For trailing "garbage" bytes it is difficult to assert that those lost bytes at the end really are garbage that may safely be ignored. I have two CD/DVD devices one consistently reports longer files than the other on reading the same CD/DVD. Luckily, for me, for the one reporting the longer file, its reading is always longer than the length of the iso that I used to burn. I truncate the longer file to match the iso and a always get a matching message digest. If the message digest of the leading part of the file matches the whole of the iso, and if the iso is a well constructed image of what should be on a CD/DVD, then a CD/DVD reader should never look at those extra bytes that dd reports at the end. A second comment: In my experience, the iso files that I download from Debian always have lengths that are integral multiples of 1024 bytes. I think there is already some padding going on in the creation of these files, so partial sectors in the iso is probably not an explanation for whatever difficulties one may be having in verifying a CD/DVD. (On doing a little quick research, I think the sector size on CD/DVD may be 2048 bytes. I don't make a claim for integral multiple of 2048 because that is not what I actually tested. I don't remember whether the integer was odd or even, just that there was no remainder.) My problems with the beautiful one or two line checking script are indicative of a little extra complexity here. Manufacturers don't, apparently, guarantee reliable, accurate end-of-file checking. If you are unlucky and have hardware with unreliable EOF sensing, you need to take extra measures in verifying the accuracy of a burn. HTH -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
