Question #205270 on Duplicity changed: https://answers.launchpad.net/duplicity/+question/205270
Timandahaf posted a new comment: Okay, I took a look. Actually the way it works is: - Uncompressed data in blocks of 128kB are sent to GPGFile or GZipFile - the size of the written (compressed) gpg or gzip file is checked against volsize - this process continues until volsize is hit Where it gets tricky is this: both Gpgfile and Gzipfile write a footer when close() called. Unfortunately, I haven't found a way to predict the size of this footer in advance. The footer size seems to vary quite a bit depending on the data. I don't even know if I can find a bound on this footer - if I could, this would solve the problem. As a kludge, I could assume that the footer will take up to 128kB, and reserve that much space for it. This will probably work in 99% of the cases, and I've tried it on volsizes of upto 250MB. What do you think? As an aside, the GzipWriteFile uses 128 kB blocks as shown above, but inconsistently uses a value of 32 kB to check for the last block. Fixing this will essentially apply my idea above to the gzip case. For the gpg case, we'll simply reduce the specified size by 128 kB. -- You received this question notification because you are a member of duplicity-team, which is an answer contact for Duplicity. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
