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.
snip
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]
