! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Incorrect mime handling when multiple mimetypes are present in mimeinfo.cache
Status:
RESOLVED: WONTFIX
Product:
Thunar-vfs
Component:
General

Comments

Description Yves-Alexis Perez editbugs 2008-11-01 08:23:54 CET
Hi,

a Debian user reported a problem against thunar 0.4.0, which I can reproduce on thunar 0.9.91. When using the “open with” menu on a jpeg file, it doesn't show the apps for image/jpeg but those for image/pjpeg (in /usr/share/applications/mimeinfo.cache).

I'm not sure if it wrongly detects the mimetype as image/pjpeg (progressive jpeg) instead of image/jpeg or if it wrongly detects the applications for image/jpeg and take those for image/pjpeg.

I'll try to investigate but in the meanwhile, if you have any idea…

Cheers,
Comment 1 John Lindgren editbugs 2009-01-04 14:07:50 CET
I did some investigation as to why this happens.

When thunar_vfs_mime_database_store_parse_file loads mimeinfo.cache, it
calls thunar_vfs_mime_database_get_info_locked to get an I.D. for each
MIME-type entry in the file.  thunar_vfs_mime_database_get_info_locked
"unaliases" some of these type names; for example, it changes
image/pjpeg to image/jpeg.  As a result,
thunar_vfs_mime_database_store_parse_file creates two entries for
image/jpeg in Thunar's database -- the original image/jpeg entry and the
one that was image/pjpeg.  When
thunar_vfs_mime_database_get_applications goes to find programs that can
open a JPEG file, it reads only one of those entries (the one that came
last in mimeinfo.cache, as it happens).

Thus when the image/pjpeg entry comes after image/jpeg in
mimeinfo.cache, programs that can load normal JPEG's but not progressive
ones are not shown.

As I see it, there are three ways to fix this behavior.  The easiest is
to leave out the "unaliasing" code altogether, but this may have
consequences that I'm not aware of).  The second is for
thunar_vfs_mime_database_store_parse_file to merge entries with
duplicate MIME types.  The third is for
thunar_vfs_mime_database_get_applications to be prepared to read
duplicate entries.  I don't think this last solution is practical since
we would have to abandon g_hash_table_lookup and look up matching
entries in the database some other way.
Comment 2 Yves-Alexis Perez editbugs 2009-01-21 07:00:08 CET
John provided a simple patch which workarounds the problem. It's quick and dirty so before any intent to apply it to our Debian sources I'd like some upstream comment on it, if it's possible (Jannis? I know you don't yet know everything about thunar, but just in case? :)
Comment 3 Yves-Alexis Perez editbugs 2009-01-21 07:00:36 CET
Created attachment 2102 
Workaround the mime type problem
Comment 4 Yves-Alexis Perez editbugs 2009-06-17 05:58:01 CEST
Jannis, could you look at that when you have some time? I'm really not sure about the patch so I guess there's a better way to do that, but…
Comment 5 Yves-Alexis Perez editbugs 2009-11-15 18:35:24 CET
Jannis, did you had time to check the patch?
Comment 6 Yves-Alexis Perez editbugs 2009-11-21 10:15:51 CET
It seems that I have two more users hitting that bug at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547623

Would it be bad to apply the patch provided by John?
Comment 7 John Lindgren editbugs 2009-11-21 16:34:05 CET
As I've just noted on Debian #547623, #547623 is not the same bug as this one and applying this patch does not fix #547623.
Comment 8 Nick Schermer editbugs 2014-12-03 09:19:07 CET
Close bug reports of archived products.

Bug #4547

Reported by:
Yves-Alexis Perez
Reported on: 2008-11-01
Last modified on: 2014-12-03

People

Assignee:
Jannis Pohlmann
CC List:
5 users

Version

Version:
unspecified

Attachments

Workaround the mime type problem (625 bytes, patch)
2009-01-21 07:00 CET , Yves-Alexis Perez
no flags

Additional information