Multiple problem of the use of a temporary folder by Déjà Dup
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
Changed in deja-dup: | |
importance: | Medium → High |
Changed in deja-dup: | |
milestone: | none → 13.4 |
Changed in deja-dup: | |
milestone: | 13.4 → 13.5 |
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.