Re: [Duplicity-talk] Tarfile support

[Ben Escoto]

>>>>> "RB" == Rob Browning <address@hidden>
>>>>> wrote the following on Tue, 18 Mar 2003 23:37:07 -0600

  RB> What are the alternatives?  For example, what are the limits on
  RB> afio archives?  I seem to recall that afio might try to to
  RB> better than cpio, but I don't know how much better.  Also, does
  RB> star fix the (age old) issues with hard links, filename lengths,
  RB> etc?  From briefly looking at star's documentation, it *sounds*
  RB> like it's better than gnu tar, though it still has a 1024 byte
  RB> path limit.

star does seem better than tar, and it supports extensions (but
apparently "vendor-specific") to store ACLs and EAs.

  RB> I briefly wondered if it might be possible (and not completely
  RB> crazy) to try creating a simple duplicity specific format.  If
  RB> ar, tar, or similar had enough minimum functionality across
  RB> platforms, perhaps you could just write 2 files to the archive
  RB> per real file, one with the file metadata, and the second with
  RB> the file data.  The metadata file would also contain the file's
  RB> real (long) name, etc.  This should allow you could accomodate
  RB> arbitrary filename lengths, have smarter hard-link handling,
  RB> etc.

Yes, probably making a new file format would be easiest.  In fact, I
probably should have done that from the start, but I thought people
would be reassured by having their archives in tar format (underneath
the GPGing).  But probably no one untars their archives anyway, and
even if they do they have to worry about applying all the diffs, which
is impractical if they are just using "rdiff" by hand.

  RB> However, after thinking about it, being able to collect (and
  RB> restore) the metadata portably sounds like a moderately hard
  RB> problem (though I suppose perhaps you could build on existing
  RB> code), and you would also end up with the very serious
  RB> responsibility of making sure your archive/unarchive code was
  RB> *absolutely correct*.

It wouldn't be that hard now because rdiff-backup (for speed purposes,
and to preserve metadata not supported by destination file systems)
already has a file format for recording all the metadata.  All that
would be left storing the data in regular files.  For that we could
use a simple file format like:

<bytes in filename> filename <bytes of data> data
<bytes in filename> filename <bytes of data> data
...


-- 
Ben Escoto

pgpmgrvKcdCbL.pgp
Description: PGP signature