On Wednesday 15 October 2008 04:37:07 Matthew Rhoten wrote: > I ran across this same problem at work recently. FindFirstFile, and > _stat/_wstat if you're using the C runtime, definitely don't want to see > the trailing path separator. > > But I looked at the code a little bit too. In compat.cpp I noticed that on > 9x systems, bacula-fd will call FindFirstFileA (and other -A APIs) using > UTF-8-encoded pathnames — rather than in the correct encoding for the > system/user locale. > > Are 9x backup clients even supported? If so, they will pretty much only > work with an English OS and ASCII filenames. If not, then those code paths > are stale anyway and could be taken out to simplify the compatibility layer > a bit. > > -matt
Yes, on Win 9X systems, there will certainly be problems with non-ASCII characters. However, Bacula uses the "best" API that is available. The only thing that I can imagine is that Microsoft changed the dll in which one of the API's such as FindFirstFileW is found in their SP3 that Ulrich reported he is using. If Microsoft decides to move the API's around, that is going to cause us some problems. Ulrich, could you give me a copy of the output from running the following in bconsole: setdebug level=10 client=xxx status client=xxx setdebug level=0 client=xxx where xxx is the client that is having problems. This will tell use whether or not the correct wide character APIs were found. If there are any ! characters in the APIs= lines, then there is a problem with your OS. Regards, Kern ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
