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

Jason Wilkins jason.a.wilkins at gmail.com
Wed Apr 4 06:24:49 CEST 2012


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


More information about the Bf-committers mailing list