[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: checking integrity of already written CD/DVD

On 2009-03-29_16:27:56, Boyd Stephen Smith Jr. wrote:
> In <[🔎] 20090329202842.GA3540@think.homelan>, Andrei Popescu 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?
> >$ md5sum /dev/dvd
> >
> >This should result in *exactly* the same checksum as the iso
> 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.
> head -c $(wc -c image) /dev/dvd | md5sum
> should be the same as
> md5sum image
> though.

This doesn't work for me, but something similar does. Don't know why my
system behaves as it does. Here is my situation:

I have two CD/DVD drives hdc and hdd. hdc is read only, hdd also is a burner.

I burn an iso on hdd and read it back using dd. I always get a read back that
is 5 to 10 ik blocks shorter than the iso file that I burned from. 

I put the newly burnt CD into hdc and read with dd, and I alway get a read back
the is 5 to 10 1k block longer that the original iso file.

As you might expect, the exact command given above never works for me on either
drive but ...
I can read back on drive hdc using dd into a file on disk, call it cd.iso
I then use dd to copy cd.iso to cd2.iso and specify a block count that is equal
to that of the original iso from which the CD was burnt. The MD5SUM of cd2.iso
invariably agrees with the MD5SUM of the original iso.

It seems to me this is something wrong in Linux, the kernel, and ought
to be fixable. In the past it did work without all the fussiness, but
not since Etch, or maybe Sarge. And it is hardware dependent. It
should be possible to automate with a script, but I haven't tried. I
only burn CDs when Debian issues a new release, so its not high on my
to-do list.

Paul E Condon           

Reply to: