Re: [rdiff-backup-users] Finding/designing a tar replacement

[Ben Escoto]

On Wed, 24 Sep 2003 18:09:13 -0700 (PDT)
dean gaudet <address@hidden> wrote:
> On Wed, 25 Sep 2003, Kevin Spicer wrote:
> 
> > I know you can use mkisofs to create an iso image without having to burn
> > it to CD, however I'm not sure if it is possible to pipe mkisofs to
> > cdrecord (I guess even if it were theres a risk of emptying the fifo and
> > making a coaster).
> 
> you can, but it is a buffering issue... mkisofs does operate in two
> passes, one to create the TOC, one to copy the files.

Firstly, my original question was ambiguous; by two passes I meant
two passes over the data to be encoded.  The example iso9660
filesystems I had seen put the path table in front of the file data,
which presumably requires two passes as Dean says mkisofs uses.
Without two passes, it won't be clear how much space to allow for the
table.

The reason I think this may be important is because, for a backup
utility, the file system may be under heavy use and could change
substantially between the first and second passes.  For instance, what
should happen if a file is missing for the second pass?  Write a 0
byte file in its place?  This seems to be a bad solution to me because
there was never a 0 byte file there.  There are probably lots of other
issues also.

> look for zisofs if you're looking for compressed isofs tools... it's also
> used by hpa's redhat superrescue images.  (there's also even more
> specialized stuff like cramfs, but it's not at all appropriate for
> duplicity due to a bunch of limitations.)

Hmm, it seems zisofs compresses the files individually, leaving the
metadata and path table uncompressed.  This isn't necessarily bad for
compression, but for encryption it would expose all the filenames.  I
will investigate encrypted filesystems though.


-- 
Ben Escoto

pgpcGYE1Dr0UU.pgp
Description: PGP signature