Merge lp:~mterry/deja-dup/tempdir-archive-dir into lp:deja-dup/26
Status: | Superseded | ||||
---|---|---|---|---|---|
Proposed branch: | lp:~mterry/deja-dup/tempdir-archive-dir | ||||
Merge into: | lp:deja-dup/26 | ||||
Diff against target: |
257 lines (+100/-48) 7 files modified
common/CommonUtils.vala (+46/-5) tests/mock/duplicity (+2/-1) tests/runner.vala (+1/-2) tests/unit/unit-tests.vala (+33/-0) tools/duplicity/DuplicityInstance.vala (+4/-6) tools/duplicity/DuplicityJob.vala (+11/-17) tools/duplicity/DuplicityPlugin.vala (+3/-17) |
||||
To merge this branch: | bzr merge lp:~mterry/deja-dup/tempdir-archive-dir | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Bruce Park | Pending | ||
Review via email: mp+155322@code.launchpad.net |
This proposal has been superseded by a proposal from 2013-03-25.
Description of the change
A little while back, for 25.5, I added code to tell duplicity to use a tempdir that is on the same partition as the source files, so that a user with /tmp as a tmpfs partition wouldn't fill it up.
However, there is one code path where we end up using /tmp anyway, that I didn't notice. If we are testing a restore in "nag mode", which is where we don't use any cached information (we re-download all the metadata and ask for the password again, hence the "nag"), we were making a call to g_dir_make_tmp. This uses /tmp, and we were filling /tmp up with our downloaded metadata.
So the solution is to use g_mkdtemp, which lets us specify a tempdir, and we'll re-use the one we create for passing to duplicity.
There's a bit of cleanup in the tests/ directory to match this new usage and to better test it.