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".
To my impression this is roughly the way it works, or more precisely:
if, for the second burn, /home/paulf/docs contains alpha, bravo
(updated), charlie, delta, and echo, mkisofs will not include the
contents of alpha, charlie, and delta in the image but make a sort of
pointer to the files which are already in the previous session instead
(I presume this is why mkisofs needs the information supplied with -C
and -M for all sessions but the first). It will incorporate bravo and
echo.
It is possible to check this if you produce the image if you change
the second number in the argument to -C to 0 (e.g. 12894,0). You can
then mount this image with the loop device, and ls should give all the
filenames present in /home/paulf/docs, but only bravo and echo should
be actually readable, the others should give you error messages or
corrupted data (such an image is not suitable for burning, though,
just for checking).
It should also become obvious if you re-burn an unchanged large
directory which is already in some prior session: the image for the
prior session will be roughly the size of the directory while that for
the repeated session will be only some kB.
These pointers obviously save space, but I guess it would be even more
rational not to include the unchanged files in the image in the first
place.
Bob says
> Paul,
>
> Have a look at your mkisofs in your original post above. All you
> are doing is re-recoding the contents of your cdrom.
>
It would be helpful to quote the line you mean here. If it is
> > > (First burn)
> > >
> > > mkisofs -r -o /tmp/cdimage /home/paulf/cdrom
> > > cdrecord -v -multi speed=4 dev=0,0,0 -data /tmp/cdimage
> > >
> > > (Second burn, after creating a new bunch of stuff to backup)
> > >
> > > NEXTTRACK=`cdrecord -msinfo dev=0,0,0`
> > > mkisofs -r -o /tmp/cdimage -C $NEXTTRACK -M /dev/cdrom \
> > > /home/paulf/cdrom
> > > cdrecord -v -multi speed=4 dev=0,0,0 -data /tmp/cdimage
I do not agree, since I think Paul is saying that the contents of
/home/paulf/cdrom have changed.
I do not know exactly why you cannot see the contents of the second
session, but I would try out the following:
- make sure your CD writer is not mounted while burning
- omit the '-data'. I think it is unnecessary and I seem to remember
it has caused trouble with me.
- do not say '-M /dev/cdrom', but '-M 0,0,0'
- mount the CD for checking whether the new files are present not as
you normally would using an fstab entry ('mount /cdrom' or so), but
with explicitly saying something like
mount -t iso9660 /dev/hdb /cdrom
(you have to be root to do that)
- take it out of the CD writer, put it into a different drive capable
of reading CD-ROMs and mount it there to check
Some of these measures have worked for me (as, indeed, the last one!),
some are no more than vague suspicions. If all fails, try out closing
the disk and see whether you can see the other sessions _then_. I
think some drives simply behave like that (if this is the case, it is
a bit unfortunate, because you have to close a disk with incremental
backups prior to restoring the files. Moreover, you cannot check the
files on the CD after the backup.) - ffi, maybe check out
http://www.tldp.org/HOWTO/CD-Writing-HOWTO.html
Would be very interested to know if any of this works.
Florian
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
