duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Tarfile support


From: Ben Escoto
Subject: Re: [Duplicity-talk] Tarfile support
Date: Wed, 26 Mar 2003 11:03:47 -0800

>>>>> "RB" == Rob Browning <address@hidden>
>>>>> wrote the following on Mon, 24 Mar 2003 09:19:08 -0600

  RB> As long as we provide a way for the user to extract files just
  RB> given our archives (say via duplicity, or some other command
  RB> line tool), then I think this would be fine.

Yeah, this is another issue.  Right now duplicity includes "rdiffdir".
This is supposed to be like rdiff except it can patch directories.  I
would have thought something like this would be useful.  Doesn't
anyone want to patch a number of binary files at once?  In the windows
world companies want to patch their binary files, and some files like
MS doc are also basically binary.  But maybe it doesn't make much
difference under unix because everything is already text (so normal
patching works) or compressed (so rdiffdir wouldn't work either).

  RB> I wonder if we could/should design this format (and its
  RB> endcoding) to (optionally?) encode redundancy information so
  RB> that any corruption might be recoverable...
    ...
  RB> Also, if we were going to have a duplicity specific format,
  RB> would we have to worry about endianness, and could/should we add
  RB> some kind of encoding (even if we don't have redundancy) that
  RB> would make it possible, to re-synchronize on the next file if
  RB> data was lost?  I guess if we're only targetting hard drives,
  RB> just having sync markers
  RB> may not be helpful since you're unlikely to get shortened files.

Hopefully I won't have to think too much about endianness
(rdiff-backup seems to be ok between two computers of different
endianness).

As far as duplicity is concerned, if the data is encrypted, then I
assume any error will make all data in that volume unretreivable, as
the error would occur to the ciphertext (the plaintext doesn't leave
the local computer, it is just piped to gpg).


-- 
Ben Escoto

Attachment: pgpeNWO0vbzoB.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]