Comment 11 for bug 262923

>This seems more like a sqlite issue to me now, at least the fact that it's having problems opening that file.

The discussed string has origin in WIN shell API SHGetSpecialFolderPath(). There are two variants of this API. One with A postfix and one with W postfix. Each of them returns string in different encoding. The SHGetSpecialFolderPathA() has ANSI encoding, which on NT systems can be customized. On Win9x/Me systems it is hardcoded and cannot be changed. The SHGetSpecialFolderPathA() API is present in WinNT for backward compatibility. The SHGetSpecialFolderPathW() returns string in unicode (to be exact UTF16LE). Now is question which one API is used by bazaar.

I downloaded sources and tracking down value origin...

It has origin in function get_local_appdata_location() (bzrlib\win32api.py). The comment for this function says...

  Returned value can be unicode or plain string.
    To convert plain string to unicode use
    s.decode(bzrlib.user_encoding)
    (XXX - but see bug 262874, which asserts the correct encoding is 'mbcs')

Is there a property in string class which says which encoding it contains, so you can recognize if returned string was plain/unicode? If not, I think encoding should be done in low level functions.

seeing _get_sh_special_folder_path() it uses SHGetSpecialFolderPathW() so it should be encoded in unicode, but it seems that encoding is ANSI - CP1250. I don't know what is behind scenes....

Here in office I have no Czech version of OS, so I will test recommended decoding - s.decode.bzrlib.user_encoding) later from home.

>Can you reproduce this problem on a non-Windows '95/ME system?
I don't understand the meaning non-Windows '95/ME system. Anyway I have no Win9x available. But according code in create_cache_dir() it uses different path.

Regards
Bronislav Gabrhelik