On Tue, Nov 09, 2004 at 05:22:25PM +0000, Thaddeus H. Black wrote: > >The problem seems to be with cdrecord(1) not >with your images, but I never saw the problem >with earlier images; I see it only now with >woody r3. > >For example, debian-30r3-i386-binary-1_NONUS.iso >has 326262 2048-byte blocks, of which the last >150 blocks are null. If I > > dd bs=2048 count=326262 if=/dev/cdrom \ > of=debian-30r3-i386-binary-1_NONUS.iso > >then only 326244 blocks are recovered. These >include 132 of the 150 trailing null blocks, but >the last eighteen are missing. Just to be sure, >I manually add eighteen null blocks, and the >md5sum does then come out exactly right. > >Cdrecord was invoked with the -data and -pad >(default pad size == 15 blocks) options. If >relevant, the machine runs a 2.4.24 kernel. > >The question is not tremendously important and I >would not advise you to spend a lot of time on >it; but if you have seen an effect like this one >in the past, where trailing null blocks are not >recorded, I would be interested to learn of your >conclusions or observations in the matter. Hmmm. AFAIK The trailing 150 NULL blocks (i.e. 2 seconds in MSF format) are added by newer versions of mkisofs to better comply with the ISO 9660 spec. As to why older versions of cdrecord don't/won't write them, I'm not sure. Are you _sure_ they're not written? I'd be curious to see what the Read Capacity command returns on those discs... -- Steve McIntyre, Cambridge, UK. steve@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Attachment:
signature.asc
Description: Digital signature