Re: [Duplicity-talk] zfec vs. par2 (and, hello there!)

[edgar . soldin]

> > only one file can be processed at a time.
>
> It would be easy to change the cmdline zfec tool to process multiple 
> files, but what should it do with them?  I guess maybe "for FILE in a 
> b c d e ; do zfec $FILE ; done" or else "tar cjf a.tar.bz2 a b c d e 
> && zfec a.tar.bz2" would probably be the best way to handle multiple 
> files.
this was more a remark. You are totally right on this. It was rooted in 
duplicity use case, where the creating of parity, usually would have to 
be applied on  a bunch of files .
As ftplicity coder I just played with the idea to add zfec to existing 
duplicity repositories, backup data. But as duplicity is also handling 
the upload (what I want to keep) there is no way. It would be possible 
though, if I had  a script that would rsync locally created duplicity 
data to an external backup storage.

> > I don't know about the inner API as I am not python literate ... 
> > regards ede
>
> The zfec README.txt describes the API.  There is a function called 
> "encode()".  You tell it which block numbers to produce.  If you tell 
> it numbers which are >= K then it produces only "check blocks" a.k.a. 
> "parity blocks" a.k.a. "secondary blocks", and produces no file data 
> blocks.
I will read that part, if only out of interest as I don't see myself 
patching duplicity. But generally I'am very interested that future 
versions support protection against minor data errors caused by 
transmission or failing backup storage.

> http://allmydata.org/trac/zfec/browser/zfec/README.txt
Thanks a lot  ..ede