CD/DVD/ISO images, readcd adding extra bytes at EOF?

[Ben Scott]

On 9/19/06, aluminumsulfate at earthlink.net <aluminumsulfate at earthlink.net> wrote:
> I too have seen something like this... ironically enough only on Red Hat 6.

  FWIW, this was on Debian "Etch" (current "testing"), with kernel
2.6.17.  The drive was a Plextor 716 connected via Firewire.

  Hmmm, I'll try it with another drive when I get home tonight, just
to see if it makes a difference.

> When copying data cds using dd (with no count= argument) ...

  I know dd doesn't always do the right thing when it comes to CDs.  I
assume this is because CDs are not, technically, simple block devices,
like hard disks are.  You can have multiple sessions, multiple tracks,
and various other magic I don't understand.  The readcd command
understands the CD magic and does the right thing.  Or so I'm told.

> Ever since then, I run an extra "dd skip=" just to make sure it got the right
> device length.

  Hmmm.  Good idea, and something I'll keep in mind in the future.
But I really don't want to get in the habit of truncating things
without understanding what the heck is going on.  :)

> I don't know how readcd reads the cd, but I know that dd has a
> "conv=sync,noerror" option.  This tells dd, when it encounters a read
> error, to pad the read sector with ASCII 0 and to try to keep reading.

  No command reported any errors (other than the cmp mismatch), and
there was nothing bad in the kernel log.

> So, maybe the actual spiral of pits pressed into the surface
> of the disk is a few sectors shorter than the disc's table of contents
> claims it is.

  I would expect that to result in some kind of I/O error, SCSI puke,
or similar.  I've certainly seen *plenty* of those before.  :)

> Or it could just be one of tohse Red Hat things. :)

  In all seriousness, I've had this sort of thing happen with the
discs from other distributions, and obviously I wasn't running Red Hat
at the time, so I don't think that's it.

-- Ben