On Thu, Jun 9, 2011 at 9:27 AM, Michael Terry
<email address hidden>wrote:
> Ken, I recall that it checks free space requirements in /tmp, but does
> it do so for ~/.cache?
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/403109
>
> Title:
> Doesn't check for free space in archive dir when backing up
>
> Status in Déjà Dup Backup Tool:
> Confirmed
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> Running latest version from ppa:
> deja-dup 10.1-0jaunty1
> duplicity 0.6.02-0jaunty1
>
> When initiating a backup, deja-dup calls duplicity with --archive-
> dir=/home/user/.cache/deja-dup however it needs to check to make sure
> this directory actually has sufficient free space available. In my
> case, it silently ate up all my free space (only about 400M at the
> time) and then stopped the backup (after only backing up about 30G out
> of 120). This then caused multiple other applications to crash.
>
> Perhaps more importantly, Deja Dup should give some indication of the
> necessity for this free space in the first place! I assumed that when
> backing up *to* another drive (with 500G+ free) it would not be a
> problem. You should also let the user choose the location for these
> files, in case they need to store them on another drive or partition
> with sufficient free space.
>
> How much space does the archive dir usually consume? Is it dependent
> on the number of files backed up? Is this directory required in order
> to restore later, or is it only for making future incremental
> backups? I've never used duplicity before so I'm not familiar with
> it, but if possible it might be worth having an option to disable it
> completely. It sounds like it is only storing unencrypted copies of
> the signature files here, right? The same files which are on the
> backup medium itself, so they couldn't they just be re-read?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/deja-dup/+bug/403109/+subscriptions
>
No, it does not. Will add that check as well.
On Thu, Jun 9, 2011 at 9:27 AM, Michael Terry
<email address hidden>wrote:
> Ken, I recall that it checks free space requirements in /tmp, but does /bugs.launchpad .net/bugs/ 403109 user/.cache/ deja-dup however it needs to check to make sure /bugs.launchpad .net/deja- dup/+bug/ 403109/ +subscriptions
> it do so for ~/.cache?
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https:/
>
> Title:
> Doesn't check for free space in archive dir when backing up
>
> Status in Déjà Dup Backup Tool:
> Confirmed
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> Running latest version from ppa:
> deja-dup 10.1-0jaunty1
> duplicity 0.6.02-0jaunty1
>
> When initiating a backup, deja-dup calls duplicity with --archive-
> dir=/home/
> this directory actually has sufficient free space available. In my
> case, it silently ate up all my free space (only about 400M at the
> time) and then stopped the backup (after only backing up about 30G out
> of 120). This then caused multiple other applications to crash.
>
> Perhaps more importantly, Deja Dup should give some indication of the
> necessity for this free space in the first place! I assumed that when
> backing up *to* another drive (with 500G+ free) it would not be a
> problem. You should also let the user choose the location for these
> files, in case they need to store them on another drive or partition
> with sufficient free space.
>
> How much space does the archive dir usually consume? Is it dependent
> on the number of files backed up? Is this directory required in order
> to restore later, or is it only for making future incremental
> backups? I've never used duplicity before so I'm not familiar with
> it, but if possible it might be worth having an option to disable it
> completely. It sounds like it is only storing unencrypted copies of
> the signature files here, right? The same files which are on the
> backup medium itself, so they couldn't they just be re-read?
>
> To manage notifications about this bug go to:
> https:/
>