On Feb 7, 2012, at 5:36 PM, Mark Hammond wrote:
> Re-added python-win32 - please follow-up there.
>
> On 8/02/2012 1:06 AM, Scott Leerssen wrote:
>> Thanks Mark. You wouldn't happen to know the encoding of the 8.3
>> filename, would you? I'm having a heck of a time setting that value
>> with Japanese characters in it. win32file.SetFileShortName purports
>> to take a PyUNICODE, but I get invalid parameter exceptions with
>> unicode Japanese strings.
>
> win32file.SetFileShortName always calls SetFileShortNameW - thus, passing a
> Unicode object avoids any encoding at all.
>
It looks like I may be missing something environmental resulting in a unicode
conversion that produces a value that SetFileShortName[W] doesn't like. I'm
using WinPE to try to set them; possibly a locale issue.
> I can't find much in the way of references, but it seems that shortnames are
> restricted to bytes and I'd expect Japanese characters to be multi-byte - so
> may simply be invalid. Have you tried an ascii name? If that also fails,
> then the API docs for that function list some additional restrictions you
> might need to follow.
I'm fairly certain the shortname will accept wide characters. 'dir /x' on a
japanese install shows japanese shortnames (3 symbols plus tilde, number and
extension, consuming 12 bytes). I can extract a utf-8 form of multibyte
character shortnames using the ntfs-3g linux hooks in getfattr and replace them
with setfattr, preserving the japanese version of shortnames from one system to
another. Using SetFileShortName, ascii shortnames do indeed work, but any
multibyte (even accented characters) result in an exception. I think I'm going
to punt and just set them with 'fsutil file setshortname' on the target after
restoring the files to their original paths.
Thanks for the replies!
Scott
>
>
>>
>> Thanks, Scott
>>
>> On Feb 6, 2012, at 5:40 PM, Mark Hammond wrote:
>>
>>> On 7/02/2012 2:45 AM, Scott Leerssen wrote:
>>>> I'm trying to open files with names that contain Japanese
>>>> characters, and found that win32file.CreateFile would raise an
>>>> exception indicating that 'The filename, directory name, or
>>>> volume label syntax is incorrect'. I found win32file.CreateFileW
>>>> (documented to deal with 'unicode'), and that did return a handle
>>>> for me. What puzzles me is that both functions take a PyUNICODE
>>>> filename, so I just assumed that CreateFile would deal with the
>>>> unicode pathname I was giving it. So, my question is, should I
>>>> just use win32file.CreateFileW instead of win32file.CreateFile,
>>>> and is it safe to use for all file handles, including those that
>>>> do not have wide characters?
>>>
>>> The short story is that CreateFile will take unicode strings and
>>> use the "mbcs" codec to convert them to the bytes required by
>>> CreateFile. Sadly that codec doesn't throw an error on characters
>>> that can't be converted (ie, characters outside the current
>>> code-page) - you just get a string with "?" chars in it. You could
>>> try manually doing 'filename.encode("mbcs")' and see if you get
>>> such chars. CreateFileW should be safe for any filename (although
>>> if you pass a str object to it, it will attempt to decode using
>>> mbcs - ie, the str must already be in mbcs format). As mbcs==ascii
>>> for all ascii chars, you never see the problem on filenames with
>>> only ascii chars.
>>>
>>> Mark
>>>
>>>>
>>>> Thanks, Scott _______________________________________________
>>>> python-win32 mailing list python-win32@python.org
>>>> http://mail.python.org/mailman/listinfo/python-win32
>>>
>>
>
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
