Page MenuHome

Username with special chars in Windows 7
Closed, ResolvedPublic

Description

With Windows 7 pro 64bit and blender 2.63a i get an error if my username contains special chars, like "сидорович" (russian). Output follows:

>>>
found bundled python: C:\games\blender-2.63a-release-windows64\2.63\python
Traceback (most recent call last):
File "C:\games\blender-2.63a-release-windows64\2.63\scripts\modules\bpy\utils.
py", line 484, in user_resource
_os.makedirs(target_path)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 14
4, in makedirs
makedirs(head, mode, exist_ok)
File "C:\games\blender-2.63a-release-windows64\2.63\python\lib\os.py", line 15
2, in makedirs
mkdir(name, mode)
WindowsError: [Error 5] Access is denied: 'C:\\Users\\С\u201eРёС\u201aР°С\u040fС
\u2021'
<<<

I get this error when installing some plugin (in fact just pressing ctrl+alt+u>addons>install addon>ok button). If i try to save or load my work i see an empty:

C:\Documents and Settings\

Even if i have users written only with normal symbols like "james" or "brown" and my testuser "сидорович" in the same folder.

Event Timeline

note that this was a problem on linux too but its been fixed now, on windows Im not sure why it persists but the error looks to be caused by bad encoding?

Will try to reproduce on my laptop.

Can confirm it's not fixed on windows.
Seems that issue happens in bpy_user_resource function: BLI_get_folder returns folder in cp1251 codepage in this case. Probably just converting path to utf8 would help. But maybe this is supposed to happen from python's side?

Anyway, even if that's supposed to happen from python's side, subdir is passing in utf8 but BLI_get_folder still works with cp1251 and this might cause some issues.

Campbell, can you please look into this?

I just tested with the name "сидорович" and this works for me on windows XP, creating a dir.

Both...
bpy.utils.user_resource('SCRIPTS')
bpy.utils.user_resource('SCRIPTS', create=True)

@Wintch, its possible when copying out of a web browser the encoding is changed, could you make an empty directory with this name, zip it, and attach to this post?

The issue is in fact that environment variable is ignored on windows:
PYTHONIOENCODING=utf-8:surrogateescape

I've committed a workaround for now, which is to manually force the encoding:
PyRun_SimpleString("import sys, io\n"
"sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8', errors='surrogateescape', line_buffering=True)\n"
"sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8', errors='surrogateescape', line_buffering=True)\n");

Whats most strange is that when running blender from a console (cmd.exe) calling this befor starting blender works:

set PYTHONIOENCODING=utf-8:surrogateescape

I tried calling BLI_setenv at the beginning of blenders main() to ensure its set early enough, and printed the value to make sure its being set properly, but its set, just python ignores it.

setting as a TODO since this is really a workaround and not a fix.

The workaround caused bug [#32720], reverted the workaround and re-opening this one.

For the record, this is the corrected line, that doesn't cause [#32720], but it an assert() in MSVC90.DLL when quitting blender, so Im not going to apply it.

PyRun_SimpleString("import sys, io\n"
"sys.__stdout__ = sys.stdout = io.TextIOWrapper(io.open(sys.stdout.fileno(), 'wb', -1), encoding='utf-8', errors='surrogateescape', newline='\\n', line_buffering=True)\n"
"sys.__stderr__ = sys.stderr = io.TextIOWrapper(io.open(sys.stderr.fileno(), 'wb', -1), encoding='utf-8', errors='surrogateescape', newline='\\n', line_buffering=True)\n");

Mailed python developer list on this issue.
http://mail.python.org/pipermail/python-dev/2012-October/122052.html

Submitted a patch to python3.4, the issue is open in their tracker:
http://bugs.python.org/issue16129

Python guys dont seem interested to give a way for us to set the encoding for sys.stdout short-term.

So temp workaround is to start blender from a .BAT file and set your environment variable from that.
---
set PYTHONIOENCODING=utf-8:surrogateescape
blender.exe
---

setting as todo since this is a python issue and its reported in their tracker.

re-applied workaround r52739. closing.

removed workaround, it stops the stdout from being writable on exit (no memfree prints)

an additional info to the issue described in [#34189]:

i noticed, that there is no that issue, when i am in an environment of
windows 7 sp1 64bit (german version, german keyboard layout / german as default input language)...

that issue i can only reproduce on that environment:
windows 7 sp1 64bit (english version, german keyboard layout / german as default input language)

I get the same issue as Alexander. I'm trying to import OpenStreetMap data and printing to the console but \u2019 (right special quote) crashes out. To reproduce:
1. create new file
2. open text editor and add new text block
3. type "print(['\u2019',])"
4. click Run Script

UnicodeEncodeError: 'charmap' codec can't encode character '\u2019' in postiion 13: character maps to <undefined>

Win8 x64 english 2.66

duplicate reported [#36642]

Forgot to say it here, but a patch allowing to fix once and for all that kind of issues has been accepted in python3.4, which final version is expected on February 2014, so we should soon be able to fix this old bug!

Bastien Montagne (mont29) changed the task status from Unknown Status to Resolved.May 1 2014, 4:34 PM

Closed by commit rBbb5b608deb31.