Hopefully GetShortPathName won't be in final release and issue will be fixed. Yes, patching zlib will work too. (this might be even better method) I will try to fix it over the weekend.
On Wed, Apr 4, 2012 at 12:29 AM, Jason Wilkins <[email protected]>wrote: > Forgot to say, another solution may be to patch zlib so that it calls > the appropriate functions on Windows? > Wouldn't that make sure that the lib is linked to the correct runtime? > > On Tue, Apr 3, 2012 at 11:24 PM, Jason Wilkins > <[email protected]> wrote: > > I think you put it too mildly when you say GetShortPathName is not the > > "best" solution. GetShortPathName may return exactly the same path > > with wide characters that it was given. If we cannot solve this then > > we should at least tell the user why because currently it just fails > > mysteriously. > > > > Or am I just weird for turning a feature I barely needed in 1995 off ;-) > > > > On Tue, Apr 3, 2012 at 10:43 PM, Alexandr Kuznetsov <[email protected]> > wrote: > >> Hi. > >> > >> Thanks for the patch. I will commit warning fixes soon (or you can do > it). > >> Concerning GetShortPathName, I know it is not best solution and it is > >> already caused problem when creating a file. > >> The problem (afaik) is that file descriptors aren't native to windows, > so > >> each compile (and each version of vc) supports it differently. As a > result > >> if zlib is compiled with vc9 and if you use vc10, application will > crash. > >> That said, we need to have zlib compiled for each complier with correct > >> runtime. I didn't had time to get around to it. > >> > >> When it is done, we can indeed use: > >> gzdopen(_fileno(ufopen(file,mode)), mode); > >> > >> Best Regards, > >> Alex. > >> > >> On Tue, Apr 3, 2012 at 11:23 PM, Jason Wilkins < > [email protected]>wrote: > >> > >>> 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 > >>> > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
