On Sun, 12 Apr 1998, Frank van der Linden wrote:

> On Sat, Apr 11, 1998 at 04:19:23PM -0400, David Jones wrote:

> > I'm thinking of going this route.  Software-wise, I'd need something that
> > can stage an incremental backup onto a holding disk, convert it to ISO9660
> > format, then blast it to a single session of a multi-session CD.  The holding
> > disk is required, since the actual burning of the CD must be done in real-
> > time - you cannot stop writing or let your data stream underrun once the
> > write operation is in progress.

Interesting.  We condidered that here, but out backup requirements are too
large, and our budget too small, for that route.  Tapes are still cheaper
than CD-R media.

> mkisofs + cdrecord should do the trick for you. The latest version of
> cdrecord (1.6) comes with mkisofs. I'm not sure if 1.6 is out of alpha
> yet, but it works reliably for me. You can also use the cdrecord package,
> it uses 1.5.

Yeah.  These are both in the pkgsrc distribution, and they worked fine for
me.  The only gotcha is that there's a one-line kernel patch that needs to
be applied to make cdrecord work with 1.3.  This was supposed to be
applied to 1.3.1, but I think somebody told me it hadn't been.

FWIW, I *think* that multi-session CD's are basically a linked list of
sessions, where each session consists of a directory and lots of files
which are referenced by that directory.  The directory, then, also has an
entry that points to the next directory.  If all that's true, then there's
no limit implied by the format.  However, it wouldn't be surprising for
somebody's software (or even the ISO 9660 spec) to have a limit on the
number of directories it'll read.

Chris

-------------------------------------------------------------------------------
Chris Jones                                      cjones@rupert.oscs.montana.edu
           Mad scientist in training...
"Is this going to be a stand-up programming session, sir, or another bug hunt?"