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