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
