I think figured this out and submitted a possible fix to the patch tracker.
On Tue, Apr 3, 2012 at 9:38 PM, Jason Wilkins <[email protected]> wrote: > If short path generation is disabled on Windows then if you open a > file that was created after short name generation was turned off the > function GetShortPathName will return the long name. It may shorten > some of the folder names, but the file will still be the original long > name and that includes the potential for UTF16 characters outside of > the ANSI range. > > The result is that a .blend file containing Unicode characters cannot > be opened by Blender in Windows if the user has disabled short file > name generation, has not generated a short name, and that file > contains a wide character. > > The current BLI_gzopen assumes that GetShortPathName will give it a > path that contains only ANSI characters and uses a naive conversion of > just casting each short to char. No where in any documentation did I > ever find a guarantee that GetShortPathName will return a string that > can be converted this way and it did not take much for me to break it. > > So, I went to fix a warning and found a broken function. I'm not sure > what to do however because I do not understand why GetShortPathName > was being used at all. The closest I can come up with is that there > is an assumption that GetShortPathName will return a nice ANSI encoded > string that can be passed to gzopen. Maybe gzopen does not support > UTF8? > > If gzopen supported UTF8 then it seems like we could pass the filename > directly to gzopen without any of the calls to GetShortPathName or any > other encoding conversions. But this function assumes it needs to be > more complicated (and gets it wrong) and there is no documentation as > to why. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
