[plug] CDROM weirdness

[Andrew Furey]

> Try doing the md5sum twice, one after the other.  I
> have a problem where
> the first run will always fail, all subsequent runs
> will be good until
> the cd is changed.  The only reference related to
> this that I have found
> is that some floppies will fail when md5sum'med the
> first time as a
> buffer in the driver needs flushing to give a clean
> run - this seems a
> logical explanation

Unfortunately not. I did 4 runs one after the other.
All four gave the same incorrect size (4kb bigger).
The first two gave a wrong md5sum as a result, and the
last two gave two more (wrong) sums. Weird.


> I think ISO9660 tracks have to be padded out to fill
> the last sector on
> the CD, and thats what you're getting as part of the
> MD5SUM - the
> padding bytes. Hence count= fixes it as you ignore
> the padding. If this is the case, and I'm fairly
sure
> it is, there isn't much to be
> done but use a count= argument all the time.

By padding do you mean up to the nearest 1024 bytes?
Isn't that mkisofs' job? (BTW I'm specifying bs=1k all
the time.)

In any event, I can burn an image on this burner from
a disk image on this machine, take the newly burned CD
home to my box (which works fine), put it in, do dd
with no count, and get the exact same values as if I
had done a dd of the source image. In my mind this is
as it should be, it just doesn't work reading on this
drive :(

Andrew

=====
"One Architecture, One OS" also translates as "One Egg, One Basket".

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!