Description of problem:
I've got a Plextor PX-W4012S SCSI CD-RW drive that I'm trying to use
to burn a CD-R.
The iso has 332201984 bytes (162208 sectors).
cdrecord -dao says it wrote 162208 sectors (without error).
dd if=/dev/scd0 of=readback.iso bs=2048
reads in 168956 sectors.
That's 6748 extra sectors than what's supposed to be there.
hexdump shows that the extra sectors are all zeros.
Using cdrecord -tao yields the correct results.
I can produce other examples with different numbers, but all to the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. cdrecord -dao dev=/dev/scd0 original.iso
2. dd if=/dev/scd0 of=readback.iso bs=2048
3. compare files sizes/sector counts of original and readback
Data written to CD is padded compared to iso image.
Truncating the extra sectors yields a file identical to the original iso.
dd should read back the same iso that was written.
Kernel version: kernel-2.6.9-1.640smp
See also bug 127783 for contrast (dao works, tao doesn't).
BTW, I'm not convinced -tao not working there is NOTABUG.
FWIW, I have some deep suspicions about the underlying SCSI code that
I am unable to quantify more than by example. The bug may lie there
rather than with cdrtools.
well, I can only tell DAO/SAO differ from TAO ...
$ man cdrecord
In the second
case the option -isosize is needed to prevent
reading the two run out blocks that are appended by
recorder in track at once mode. These two run out blocks
be read and would cause a buffer underrun that would
defective copy. Do not use this option on files
mkisofs and in case cdrecord reads the track data
If I understand correctly the purpose of -isosize is to keep -tao from
padding a CD with zeros when it's recorded, if the track size cannot
be determined from an iso file size.
In this bug, -dao is padding the CD with zeros.
that is very strange, are you really, really sure?
normally it's the other way round! -tao pads with zeros, -dao does not.
I tried it myself several times... -dao does not pad. Maybe it's your
drive that does it wrong!??
Sorry that it's been a while.
Yes, I'm absolutely positive that I had it right. I spent/wasted
several blanks making sure.
For kicks, though, I tried again just now using the same version of
cdrecord and kernel-2.6.9-1.649smp.
Guess what? No errors with either -tao or -dao.
I'll close this bug for now, but my paranoia of the underlying SCSI