When testing a restore, don't blindly use /tmp
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Déjà Dup |
Fix Released
|
Undecided
|
Unassigned | ||
deja-dup (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Fedora and other Linux distributions have started to use a "tmpfs" for the /tmp/ directory, which has limited space available.
The new cross-distribution rule seems to be: If your application needs to place large amount of data into a temporary area, then it should use /var/tmp
The proposal here is to change deja-dup to use /var/tmp
I just ran into this myself, when deja-dup attempted to test a restore, and storage in /tmp/ was full (deja-dup wrote 3.7 GB).
However, I have to say, I'm a bit surprised by duplicity's strategy. It attempts to download ALL duplicity-
Should I file a deparate bug for duplicity?
Related branches
- Robert Bruce Park (community): Needs Fixing
-
Diff: 104 lines (+19/-26)4 files modifiedtests/mock/duplicity (+2/-1)
tests/runner.vala (+1/-2)
tools/duplicity/DuplicityInstance.vala (+4/-6)
tools/duplicity/DuplicityJob.vala (+12/-17)
Changed in deja-dup: | |
status: | New → Fix Committed |
Changed in deja-dup: | |
status: | Fix Committed → Fix Released |
And if I select "cancel" in deja-dup's progress of the verification - then deja-dup doesn't clean up the /tmp/deja- dup-*/deja- dup directory which has already downloaded 1.7 GB of data...!