Currently the command string stores the path as a string which only supports ASCII characters. This means the filepath that is passed into python isn't found when attempting to write data to the cache if it contains characters outside of the english character set. Before passing it to python I now covert it to wchar_t to support Unicode characters that could exist in the filepath.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- unity/T98467-mantaflow-unicode-characters
- Build Status
Buildable 22707 Build 22707: arc lint + arc unit
Event Timeline
Comment Actions
Can you explain the logic behind the conversions your are doing here? From a first glance it seems like the code does utf8 > wchar > utf8. From looking at the code, I don't understand how this intermediate conversion to wchar helps.
Comment Actions
Also not sure how this solves the problem exactly, it seems like a round-about solution.
Since paths are being encoded into a Python string literal in escapePath, it would seem simpler to support arbitrary bytes in the strings.
You could for e.g. use \x## encoded characters in the string or byte literal.
So the result might look something like this:
os.fsdecode(b'\x2f\x68\x6f\x6d\x65\x2f\x75\x73\x65\x72\x2f\x66\x69\x6c\x65\x2e\x74\x78\x74')
Which gets converted into /home/user/file.txt.
Comment Actions
@Jacques Lucke (JacquesLucke) you are entirely correct. I just checked in the 3.3 daily build and I actually can't recreate this bug there. When I was testing to recreate it I was using an older build and obviously never re-checked if it was still occuring in master, so I made some changes around what I thought was happening and it seemed to work. But on re-examination this code actually just converts one way, and then back again, and the bug was resolved somewhere else entirely.
Will ask the user to re-test if it's fixed for them in the 3.3 daily build.