[pywin32-bugs] [ pywin32-Bugs-2704124 ] GetCompressedFileSize fails for some unicode filenames

[SourceForge.net <no...@so...>]

Bugs item #2704124, was opened at 2009-03-23 07:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2704124&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Pending
>Resolution: Later
Priority: 7
Private: No
Submitted By: Tim Golden (tjgolden)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetCompressedFileSize fails for some unicode filenames

Initial Comment:
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>


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2009-03-30 23:28

Message:
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...

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2009-03-27 22:06

Message:
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


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2704124&group_id=78018