duplicity-team team mailing list archive

[edso <question205270@xxxxxxxxxxxxxxxxxxxxx>]

Question #205270 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/205270

    Status: Open => Answered

edso proposed the following answer:
On 08.08.2012 07:21, Timandahaf wrote:
> New question #205270 on Duplicity:
> https://answers.launchpad.net/duplicity/+question/205270
> 
> Currently --volsize <N> means "create volume sizes of <N megabytes + a fudge factor>". The use case that I would think would be more useful is to ensure that the volume size never exceeds N. This is useful in cases where there is a file size limit on the target media, for example. Does this make sense to others?
> 
> If so, should I submit a feature request to modify the behavior of volsize? If it is not very simple, I'd be happy to take a look and perhaps submit a patch.
> 

as far as i understand this is technically impossible because

- data is streamed and counted into a tar writer file object
- after count x is achieved the writer uses the compressor or gpg on it for the final volume

the difference between the compressed/encrypted and raw input is the
fudge factor. but writing it, i realize that the files should be smaller
than the raw input due to compression. so i must have got something
wrong here.

@Ken: can you shed light on this?

Timandahaf you are welcome to have a look at this and deliver patches.
there is actually another pressing issue regarding volumesize. manifests
and signatures currently do not honor the --volsize setting, which makes
duplicity unusable for some backends with enforced max filesizes.

..ede/duply.net

-- 
You received this question notification because you are a member of
duplicity-team, which is an answer contact for Duplicity.