Multiple problem of the use of a temporary folder by Déjà Dup

Bug #332505 reported by Huygens
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Déjà Dup
Fix Released
High
Unassigned

Bug Description

This is related to the bug #332500

Context:
As said before, I was trying to restore a backup (~700MB) on my hard disk which had not enough free space (~400MB).
The restore failed.
First surprised: no data restored in the destination folder?!?
Second one: little space available on my primary hard disk (~5MB)!?!
Third one: ha! there are some restored data in my /tmp folder!

Problems:
1/ Déjà Dup does not move the partly restored data to the destination folder! I do not know if it should or not, but if it should not, then it should tell the user where the temporary files are and if he wants to delete them (to restore disk space) or browse the temporary folder.

2/ As reported in bug #332500 Déjà Dup should check for disk space on the destination folder. Furthermore, it should check for disk space in the /tmp folder (or partition). In case the /tmp folder is too small for the restoring process, a solution should be found: a/ just notify the user with an explicit error message ; b/ ask the user to use another temporary folder where disk space is sufficient ; c/ do not use a temporary folder and directly restore to the user specified destination folder ; d/ a mixture of the three previous one with the choice left to the user

Revision history for this message
Michael Terry (mterry) wrote :

1) It should at least tell the user where they are, I agree. If there's an error moving the files from the temporary folder, it does tell the user that their files are there. I had thought we did the same thing if there was an error during the actual restore. It must be an oversight. Good catch!

2) Agreed, that there should be some attempt to be cleverer in this case. But I'd like to avoid bothering the user for such a thing if possible. I like the idea of, if after checking /tmp and there isn't enough space, just falling back to another temp directory (possibly in the user's home directory?). I'll have to think about it. And obviously, checking that fallback destination as requested in bug 332500.

Changed in deja-dup:
importance: Undecided → Medium
status: New → Confirmed
Michael Terry (mterry)
Changed in deja-dup:
importance: Medium → High
Revision history for this message
tomdryer (tomdryer-com) wrote :

Fixing this bug should be top priority. As far as I can see, anyone using separate /home and / partitions can't restore significant amounts of data with Déjà Dup because of this.

Does anyone have a workaround for now?

Revision history for this message
Michael Terry (mterry) wrote :

One workaround is to specify a different tmp dir. Something like:

TMPDIR=/home/me/tmp deja-dup

Michael Terry (mterry)
Changed in deja-dup:
milestone: none → 13.4
Michael Terry (mterry)
Changed in deja-dup:
milestone: 13.4 → 13.5
Revision history for this message
Michael Terry (mterry) wrote :

Now that duplicity 0.6.07 has been released, with its support for the --rename argument, I can finally mark this fix released. Deja Dup has supported that argument's use since 13.5. This means we no longer need to backup everything to /tmp first.

Changed in deja-dup:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.