On Thu, Oct 30, 2003 at 03:05:47PM +0100, [EMAIL PROTECTED] wrote:
>
> Paul writes
>
> > > There must be something I don't understand about this. For the sake of
> > > brevity, here's an example. First burn is /home/paulf/docs. It contains
> > > the files alfa, bravo, charlie and delta. I make an ISO of this, stored
> > > in /tmp/cdimage. I burn it to CDR and delete the /tmp/cdimage file. A
> > > week later, I've updated the bravo file and added an echo file. Now I
> > > make an ISO of the /home/paulf/docs directory, and burn that to
> the CDR.
> > > Now when I look on the CDR, what I see is the _original_ burn. All this
> > > is using the commands I mentioned above (normally I'd snip email,
> > > but...).
>
>
> > > Now, my original thought was that mkisofs/cdrecord process would simply
> > > add the new echo file, and show an updated version of the bravo file,
> > > while leaving the rest alone. Sort of like the way it works on a hard
> > > drive, except that the space taken up by the old versions of files
> (like
> > > bravo) would still be "used".
>
>
> PS: in case anyone is interested, I have written two Perl scripts
> intended to make full and incremental backups on CD-R more
> convenient. The first puts a large number of files on several iso9660
> CDs (without any archiving or compression, just like that) and the
> second adds sessions to a multisession disk with some safety
> measures. The first script also can collaborate with the second by
> burning the last disk in multisession mode, so as to make the
> remaining space available for further incremental backups. Both are
> thoroughly tested by myself and work fine for me, although the
> session-adding script is sometimes provoking errors from the SCSI
> adaptor driver. This should be a problem of the latter (beta), not of
> the script.
>
I'd be interested in your scripts. Meantime, I solved the original
problem. I don't know what I was doing wrong, but I read every bit of
documentation I could find and understand. Most helpful was the
README.multi that comes with cdrecord. The following is roughly how it
works:
# FIRST Burn
# Make image
mkisofs -r -o /tmp/cdimage /home/paulf/cdrom
# Test image
mount /tmp/cdimage -r -t iso9660 -o loop /cdrom
mc /cdrom
umount /cdrom
# Actual burn
cdrecord -v -multi speed=4 dev=0,0 /tmp/cdimage
# Test CDR
mount -t iso9660 -o ro /dev/cdrom /cdrom
mc /cdrom
umount /cdrom
# Delete image
rm /tmp/cdimage
# LATER burns
# Make image
TRACK=`cdrecord -msinfo dev=0,0`
mkisofs -o /tmp/cdimage -r -C $TRACK -M /dev/cdrom /home/paulf/cdrom
# Test image
TRACK=`cdrecord -msinfo dev=0,0`
FIRST=${TRACK%%,*}
mkisofs -o /tmp/cdimage2 -r -C $FIRST,0 -M /dev/cdrom /home/paulf/cdrom
mount /tmp/cdimage2 -r -t iso9660 -o loop /cdrom
mc /cdrom
umount /cdrom
rm /tmp/cdimage2
# Actual burn
cdrecord -v -multi speed=4 dev=0,0 /tmp/cdimage
# Test CDR
mount -t iso9660 -o ro /dev/cdrom /cdrom
mc /cdrom
umount /cdrom
# Delete image
rm /tmp/cdimage
Some notes: It is possible to determine if a disk has been burned before
by checking the results of cdrecord -multi dev=0,0. If empty, then so is
the disk. This would allow a script to determine which branch to take
(virgin or already burned). Also in testing the above, I also note that
sometimes the kernel is dumb about what's on the CDR. Apparently, when
testing the image burned on the CDR from later sessions, Linux will
sometimes think nothing has changed from the last burn. It appears that
if you eject the disk, it usually resolves this problem. It may be that
a simple sync command will do the same thing. But lack of doing this may
lead the user into believing that their burn was unsuccessful somehow,
even though the system appeared to actually burn the CD.
Paul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
