On 10/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Depending on the drive, you may also need to write multiples of 2048 bytes, padded if necessary. tar writes multiples of 512 bytes, so using dd to pad it might be necessary. Even then, if you write directly to /dev/sdD0/data, you'll need to fixate (close) the disc.
Typical drives accept only 2048 bytes/sector (or variations for certain types of recording where you write not only data but also have to supply all that additional data which makes CD a 700 MB instead of full 1 GB :>). IIRC 2048 b/s is standard sector size for data in CD-ROM standard
From what I know, drives supporting 512 bytes/sector are mostly (If
not only) SCSI (and similar, although I don't think anybody made FiberChannel CD-RW ;-) ) drives. On such drives you can find additional jumper which sets either 512 or 2048 bytes per sector. Example of such drive is Yamaha 16x4x4 Fast SCSI-II CD-RW. AFAIK the only system which requires such setting is VMS, which uses only 512 mode. I'm not sure, but I think that specification doesn't have option for switching sector size on the fly and propably has fixed data structures which break if incompatible modes are selected.
I'm not sure what there is to fear about iso 9660 format. It doesn't encrypt your data and files tend to be written contiguously (I'm not sure if that's required by the format or just a good idea to make reading faster), so digging the data out by hand shouldn't be difficult if suddenly all the world's 9660-reading programs stopped working.
As long as nobody starts to put important data in subchannels or uses some of the wierder aspects of ISO9660 (Multiple disk filesystems? Is there any program which is capable of making those at all??). Most common, single session CD's have metadata at the beginning, then files. Multi-session add pointer for 'updated descriptor' or something like that which is address of next descriptor in chain (next session). At least I think it should be much easier to decode (as long as it's pure-data track, without any subchannel craziness) than NTFS (which, to my big surprise, was much easier to decode by hand than ext2....). -- Paul Lasek
