http://bugs.winehq.org/show_bug.cgi?id=28158
Summary: [integration] winemenubuilder forces lower case when searching fd.o mime database Product: Wine Version: 1.3.26 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs@winehq.org ReportedBy: wine@rodrigosilva.com
When winemenubuilder searches for freedesktop.org xdg mime database, and build its list native extensions and mime types, it always searches and tries to match a lower case string. Windows registry might be case-insensitive, but native mime database is not, and (unfortunately) some extensions (globs) and mime types do have upper case chars. Some examples:
audio/AMR:*.amr audio/AMR-WB:*.awb text/x-c++src:*.C application/x-compress:*.Z application/x-blender:*.BLEND text/x-iMelody:*.ime text/x-iMelody:*.imy text/css:*.CSSL application/x-gnome-saved-search:*.savedSearch
I am just listing "regular" globs that could be directly mapped to windows extensions (as opposed to things like README*, Makefile, *.tar.Z, etc)
Take Z for an example of the problem:
- Windows app register "HKCR.z". Winemenubuilder searches for *.z, can't match, so it creates the native application/x-wine-extension-z mime/glob. Unfortunate but unavoidable.
- Windows app register "HKCR.Z" instead. Winemenubuilder *still* searches for *.z, because it forces lowercase in its search! There is no match, and it creates the application/x-wine-extension-z. With *.z glob! And that is a bug.
Currently, there is no way to prevent winemenubuilder to create duplicate (and buggy) mime extensions when native glob and/or extension contains upper (or mixed) case chars.
My suggestion for fix: to really mimic Registry case-insensitivity behavior, winemenubuilder should use case-insensitive search. For example, comparing lower(win ext)=lower(fd.o glob). And if a match is not found, create the native glob *exactly* as registered by windows app.