Re: [Duplicity-talk] why pad with incompressible bytes?

[mike]

I thought I'd just mail you directly...

I've been thinking of features -

Having some options like these:
--no-deltas - don't transfer deltas, transfer entire file (the same as
rsync -W i believe)
--dry-run - to see what would be done but not act on it (rsync -n, and
not actually compress/encrypt anything either, just report what's
changed)
--max-size to tell duplicity how big of archive files to create
(basically the "filesize" variable in the GPGWriteFile and Gzfile or
whatever stuff)

that's what I've got right now. I think I thought of some others, but
for the time being ... they've skipped my brain.

- mike
On 1/11/07, Travis H. <address@hidden> wrote:
> In GPGWriteFile, I see that duplicity "tops off" the file with
> incompressible data to make it match the desired size.
>
> This seems dumb and unnecessarily complex to me.  GPG already pads the
> file to disguise its length a little bit and to make it a multiple of
> the cipher block size.  What's the advantage of making the file larger
> just to hit some desired limit without actually storing any useful
> data?
>
> I'm actually familiar enough with python (current favorite language)
> and file formats and gpg and compression that I could probably do some
> development work without too much effort.  What are the most desired
> (or requested) features?
>
> --
> ``Unthinking respect for authority is the greatest enemy of truth.''
> -- Albert Einstein -><- <URL:http://www.subspacefield.org/~travis/>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk