I have a filename which contains the unicode codepoint U+F022. win32file.GetCompressedFileSize fails to cope with this name, returning error ERROR_INVALID_NAME. I can, however, call the underlying -W function from ctypes which works correctly. I suspect that the -W version of the function isn't in fact being used. My experience is that the -A functions will work on "simple" unicode -- those which can be encoded/decoded by the default encoding -- but will fail on "deeper" unicode, such as my example above which uses a private-space code point. (It's a real-life example, altho' I've no idea how it got there).
Example:
<code>
filename = u"\uf022.txt"
open (filename, "w").close ()
import win32file
print win32file.GetCompressedFileSize (filename)
import ctypes
from ctypes import wintypes
size = wintypes.DWORD ()
print ctypes.windll.kernel32.GetCompressedFileSizeW (filename, ctypes.byref (size))
</code>
This should work correctly in Python 3, where the module is built
so that unicode API functions are called. Pywin32 can now be built
with UNICODE defined for 2.x also, although it hasn't been released
that way yet.
Roger
It is a slippery-slope from here, and I'm inclined to agree with Roger that moving to unicode builds everywhere is a better strategy than hacking every function taking a string to handle those different types. Maybe later this year - when the dust fully settles from the recent py3k-enabled builds, I'll stir more up by moving everything to unicode...
Fine by me. I have to workaround it in any case for earlier versions. Appreciate the attention.