Duplicity doesn't handle non-utf8 filenames well
Bug #1050509 reported by
Michael Terry
This bug affects 15 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
duplicity (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
This is a break-out bug from bug 989496.
If the user is using a filename encoding that is non-utf8, duplicity doesn't have special support for that. It mixes use of filenames for both printing/logging and for opening. All print/log uses should use a utf8 version of the filename. All actual file operations should use the native encoding.
This will likely involve a new field like pretty_name or something on ROPath.
I suspect the number of users with non-utf8 systems is low. So I'm setting as low priority.
To post a comment you must log in.
Much thanks for taking care of this regression here and in the other bug! I still think this bug deserves a fix, or at least a better logging of the problematic file. If for some reason a user ends up with a file with an invalid name, there's no way of finding out this is the problem from the GUI, let alone identify the file and fix its name. So backup is impossible.