[Top][All Lists]
[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
pgpeNWO0vbzoB.pgp
Description: PGP signature