Allow renaming paths as they are restored
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
= Background =
Deja Dup has this feature where if you restore your backup as a different username, it will put your restored files in your current home directory. Which would be easy if the parent directory of the backup were $HOME. But it always backs up with a parent directory of / (to allow backing up non-home directories and the like).
So, Deja Dup restores everything to a /tmp directory, renames what it needs, then moves the files to their final destination. But this has caused several bugs with available space in /tmp.
= Feature Request =
So it would be nice if Deja Dup could just pass --rename=
= Design =
I think a decent syntax would be to follow sed's example and allow a leading separator character, the input match, a separator, the output result, and a final separator. An error would occur if it couldn't be parsed.
To keep it simple, the string would be parsed as a literal string. That is, no globbing, no regular expressions. That would be over-engineering this, I think.
Each rename argument would be chained up. So the first rename would happen, then the second would run, etc.
In the case of a conflict (i.e. home/bar is already in the backup), a warning is printed, and duplicity ignores the rename. Better not to try to merge the two directories.
= Approval =
Ken, does the above make sense and desirable? I can start working on a patch.
Related branches
- duplicity-team: Pending requested
-
Diff: 92 lines (+37/-2)4 files modifiedduplicity.1 (+13/-0)
duplicity/commandline.py (+6/-0)
duplicity/globals.py (+3/-0)
duplicity/path.py (+15/-2)
Changed in duplicity: | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
Changed in duplicity: | |
status: | Triaged → Fix Committed |
milestone: | none → 0.6.07 |
Changed in duplicity: | |
assignee: | Michael Terry (mterry) → nobody |
Changed in duplicity: | |
status: | Fix Committed → Fix Released |
FWIW I think it sounds like a definitely useful feature. One implementation complexity issue I see is that answering "is X in the backup" is not necessarily simple?