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

[Alexandr Kuznetsov]

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