[Bf-committers] BLI_gzopen fails to open files with Unicode names in Windows when short path generation is disabled.

[Alexandr Kuznetsov]

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 <jason.a.wilkins at gmail.com>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 <jason.a.wilkins at gmail.com>
> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>