compile_proxies fails on win7 with non-ascii characters in user name
|Status:||In Progress||Start date:||10/30/2016|
|Assignee:||Jonas Hauquier||% Done:|
|Target version:||MakeHuman 1.1.2|
On win7 with user name åäöüû:
Could not load proxy file data\proxymeshes\proxy741\proxy741.proxy.
Traceback (most recent call last):
File "compile_proxies.py", line 71, in compileProxy
proxy_ = proxy.loadTextProxy(human, path, type=None)
File "./shared\proxy.py", line 398, in loadTextProxy
proxy._obj_file = _getFileName(folder, words, ".obj")
File "./shared\proxy.py", line 914, in _getFileName
return os.path.join(folder, file)
File "c:\python27\lib\ntpath.py", line 85, in join
result_path = result_path + p_path
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 7: ordinal not in range(128)
[88% done] converted proxy data\proxymeshes\proxy741\proxy741.proxy
(mh directory is on desktop)
#3 Updated by Joel Palmius about 2 years ago
The following patch solves the problem by working around it, but I'm unsure if I introduce other problems by using it
--- a/makehuman/shared/proxy.py Mon Sep 05 08:04:23 2016 +0200 +++ b/makehuman/shared/proxy.py Sun Oct 30 14:12:49 2016 +0100 @@ -36,6 +36,7 @@ TODO """ +import sys import os import math import numpy as np @@ -503,7 +504,7 @@ def saveBinaryProxy(proxy, path): def _properPath(path): - return getpath.getJailedPath(path, folder) + return getpath.localPath(path) fp = open(path, 'wb') tagStr, tagIdx = _packStringList(proxy.tags) @@ -910,6 +911,8 @@ def _getFileName(folder, file, suffix): (name, ext) = os.path.split(file) + if isinstance(folder,str): + folder = unicode(folder,sys.getfilesystemencoding()) if ext: return os.path.join(folder, file) else:
#5 Updated by Jonas Hauquier about 2 years ago
Changing getJailedPath into localPath is not as much as fix, as it is a change in functionality.
If there's a unicode error in getJailedPath, then that method should be fixed (if only because it is used in other parts of MH as well, which can still contain unicode errors)
Perhaps, instead of trying to fix the path to unicode in _getFileName (and creating duplicate code), pass it through getpath.formatPath()
#7 Updated by Joel Palmius about 2 years ago
- Status changed from Fix exists, needs testing to In Progress
- Priority changed from Urgent to Low
- Target version changed from MakeHuman 1.1.1 to MakeHuman 1.1.2
There are multiple places where stringToUnicode should be used. Having played around with the file a bit, I'm thinking it would merit some more effort than an attempted quick fix.
However, this isn't going to affect any real-world user, so moving to next release and downprioritizing.
Also available in: Atom