> > 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; Actually, there is a flag there that caused the convertion to UTF-16 to 'fail' (it doesn't really fail, just that the utf8ToUnicode returns 0).
> if it fails, it calls CreateFileA with > the original string. Exactly > 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. Actually, in Win98 it will pass the conversion, but as I said above, the function fails by a check: "if (!isNT())" > 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. Now that I checked the code, it actually does. Unfortunately, the way the code is setup makes it necessary for the caller to check in which OS it runs and either use UTF8 paths or ansii ones. I think this is not a good technique (and not actually intended from what I have read in the docs) since the sqlite3_open does not give a truly uniform interface to the caller. My suggestion is this: The sqlite3_open should always expect a utf8 path (as the docs say). If in win2k everything works fine. If in win98 it should convert the path to utf16 and THEN convert it to ansii using the CP_ACP (current ansii code page). This will work for 99.9% cases since in non-English win9x OS, almost 99.9% ansii strings are in the system's locale. I think this is also the expected behavior (and what I have programmed my app to do, until I tested it in win98). To make these changes, all the logic of os_win.c should change to accommodate the above. I would certainly say that the way it currently works is wrong (bug). Of course, there is the problem of breaking existing code (since many win9x user will not have read the docs, or else someone would have mentioned this behavior looong time agoe). To maintain compatibility (e.g. to accept ansii non-utf8 paths), a check can be made on whether the supplied path is in utf8 (heuristically this has almost 100% success) and then do the above. Costas > 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.
