Re: [Bug-xorriso] copy from one cd to another

[Thomas Schmitt]

Hi,

> I have two cd(dvd)-rw drives on my system, and wanted to
> copy a cd from one to another

This would be a job for the cdrecord emulation.

To copy from /dev/dvdrw to /dev/dvdrw1:

  xorriso -as cdrecord -v dev=/dev/dvdrw1 /dev/dvdrw

(xorriso's native command set is intended for creating and manipulating
 ISO 9660 filesystems. Plain burning is delegated to the emulation.)

Above xorriso run can encounter an i/o error at the end of the source CD
if it was recorded with write type TAO. This is an old Linux kernel bug,
caused by the fact that the track size of TAO includes two non-data
blocks at the end. Linux kernel tries to read ahead and drops a whole
cache tile when encountering the two unreadable blocks.
(This is why CD burning traditionally adds 300 KB of padding. So the
error does not hit vital data.)

This will work for single session data CDs.

Audio CDs cannot be read via the block device driver. One needs special
reader software like readcd. (In general, non-data is not in the scope
of xorriso.)

Multi-session CDs have unreadable gaps between the sessions. Copying
would end with an i/o error at the first gap. (One may of course get
the track start addresses and sizes and copy the CD session-by-session.)


>  xorriso -device_links reported:
> 0  -dev '/dev/dvdrw'  rwrw-- :  '        ' 'iHAS124 D' 
> 1  -dev '/dev/dvdrw1' rwrw-- :  'ATAPI   ' 'iHAS124 D' 
> 
> Which already looked unusual to me (cdparanoia -Q reported /dev/sr0),

More suspicious is the fact that the first drive does not tell
a manufacturer name.

The reason why the man page example proposes command -device_links
is in the habits of modern GNU/Linux systems. The sr addresses
get permutated with every boot. udev has longish id strings to map
always the same drive to /dev/dvdrw resp. /dev/dvdrw1.

If the /dev/sr naming of your system is stable, or if you do not
need persistent addresses, then you may use the older command
  xorriso -devices
It will talk about /dev/sr* and /dev/hd*.


> $ xorriso -indev /dev/dvdrw -outdev /dev/dvdrw1

This comand sequence would read an ISO 9660 filesystem tree from
dvdrw and aquire dvdrw1 for writing a new ISO image to it after
the loaded image tree has been manipulated.

It would copy the structure and content of an ISO 9660 filesystem
in devrw if you add some command that causes a change in image
content, or if you force writing by command -changes_pending:

   xorriso -indev /dev/dvdrw -outdev /dev/dvdrw1 \
           -changes_pending yes

This produces a new ISO filesystem, not a flat copy of the old
ISO image. A re-narration.
It works only if the source CD contains an ISO 9660 system.


> libisoburn: WARNING : No ISO 9660 image at LBA 0. Creating blank image.
> Drive current: -indev '/dev/dvdrw'
> Media current: CD-ROM
> Media status : is written , is closed

Is your source CD a data CD at all ?
Can you read data from it by e.g.

  dd if=/dev/dvdrw bs=2048 count=1 of=/dev/null


> I also tried with the arguments swapped,

In general the sequence of xorriso commands does matter, indeed.
But -indev and -outdev do not depend on each other. So they
can be swapped without much consequences for the program run.


> So I guess my request/suggestion is to put an example for this into the
> manual, if it's not already there (in which case I'd be curious to know
> where I missed it).

There is an example which is quite near to your scenario:
"
   Burn an existing ISO image file to medium
       Actually this works with any kind of data, not only ISO images:
       $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed image.iso
"
Exchange "image.iso" by "/dev/dvdrw1" and you are at my above proposal.


> BTW, Tools -> Copy CD worked fine in k3b :).

Maybe you will have to resort to such a tool. It depends on whether
the source CD is a single-session data CD.


Have a nice day :)

Thomas