fails to open files with invalid characters in the name
Bug #1958175 reported by
Louis-Philippe Véronneau
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| qpdfview |
Triaged
|
High
|
Unassigned | ||
Bug Description
This is a forward of the following bug in Debian:
https:/
I have been able to reproduce the issue on 0.4.18-6 with:
cp test.pdf $'TEST\310.pdf'
qpdfview TEST<tab>
qpdfview errors out with "Could not open 'TEST�.pdf'."
Revision history for this message
| Adam Reichold (adamreichold) wrote | #1 |
| Changed in qpdfview: | |
| status: | New → Triaged |
| importance: | Undecided → High |
To post a comment you must log in.
Hello Louis-Philippe,
this might get complicated. I have to find the exact place where this breaks, but I fear it wont be easily fixable as for example Poppler's Qt frontend accepts paths as QString [1] which are assumed to be valid Unicode AFAIU [2] whereas path not not necessarily and as the original reporter explained, the file name is invalid UTF-8 and not representable as Unicode text except for using a replacement character.
This also seems rather wide spread in the Qt ecosystem: I cannot open that file with Okteta either. Better yet, I cannot even use Dolphin to rename/delete the file. This does not seem surprising insofar Qt itself seems to handle paths as QString almost everywhere.
Regards,
Adam
[1] https:/
[2] https:/