On 8/5/06, Costas Stergiou <[EMAIL PROTECTED]> wrote:
According to the docs, the file path should be utf8 encoded. If in the path there are non-ansii chars, the following method fails in win98. Tried the following: 1. Created an sqlite3 db in a path containing greek chars 2. Tried to open it by passing the path in utf8: it works on win2k, fails on win98 3. Tried to open it by passing the path as an ansii string: works on win98 (why?), fails in win2k
Can anyone confirm this issue?
I no longer have a win98 system to test with, but based on my understanding... os_win.c attempts to convert the filename from UTF-8 to UTF-16. If it succeeds, it calls CreateFileW; if it fails, it calls CreateFileA with the original string. CreateFileW is a nonfunctional stub on win98, so when you pass a UTF-8 filename sqlite takes that codepath and fails. An ANSI filename won't pass the UTF-8 conversion, so CreateFileA is called with the ANSI string. That doesn't necessarily explain win2k though. Perhaps the current user locale does not match the ANSI encoding of the filename you're passing in? Internally win2k only uses the Unicode version, so CreateFileA must do an implict conversion to Unicode using the current user codepage. MSLU does provide a functional CreateFileW wrapper for win9x, but I don't believe the stock sqlite binaries are built with it. On 8/5/06, Peter Cunderlik <[EMAIL PROTECTED]> wrote:
I think you will never succeed using UTF-8 encoded filenames on those systems. I don't know how it can be done programmatically, but each file or directory name has its 8.3 name as well, i.e. "Program Files" would be "progra~1". I think this is the safest way how to pass filenames to SQLite. It should work on Win 9x as well as 2K and XP.
NTFS can have 8.3 shortname creation disabled. Systems running without it are not common but do exist, so you should avoid relying on them if at all possible.
