Richard wrote, > I read once on some web page that dd is not the best utility to read back > all the data on a CD. IIRC, the author recommended to 1) mount the CD, and > 2) use cat to read the data. I haven't actually tried any of this myself... It seems that Richard is right. I had not known it, but dd(1) does not appear to be the best utility to read back all the data on a CD. Steve wrote, > 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? By causing me to research sg_readcap(1), Steve's reply leads me to discover that I should have used sg_dd(1) instead of dd(1). Using sg_dd(1) to recover the .iso, no block is lost. > I'd be curious to see what the Read Capacity command returns on those > discs... # sg_readcap /dev/scd0 >>> Mapping /dev/scd0 to sg device: /dev/sg0 Read Capacity results: Last block address = 326278 (0x4fa86), Number of blocks = 326279 Block size = 2048 bytes All the blocks are there: 326262 for the image; plus 15 for the pad. Thank you. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, t@b-tk.org
Attachment:
pgpXH63JPq7_w.pgp
Description: PGP signature