Created attachment 25102 [details] [review]
xdgmimemagic.c order fix

Explanation please....

I investigated and wrote a patch for the same problem in gnome-vfs. I
sent it to jrb so that he can review it, but he didn't have time to
look at it yet. Here is the mail I sent him, I hope the explanation
will be clear enough for someone not familiar with the code. 

« The attached patch fixes a bug with the xdgmime code where any elf
executable file would be sniffed as an application/x-core file. This
happens because of a bug in xdgmimemagic.c when the magic for a mime
type is composed of several 'indented' patterns.
xdgmimemagic.c reads the patterns one by one, and each time it has read
one pattern, it prepends them at the beginning of a list. With a file
created from
<match .... />         <- indent 0
<match ....>           <- indent 0
  <match ....>         <- indent 1
     <match ... />     <- indent 2
  </match>
</match>
you'd have in memory a list composed of
(pattern with indent 2), (pattern with indent 1), (pattern with indent
0), (pattern with indent 0)

On the other hand, the code in _xdg_mime_magic_matchlet_compare_level
assumes that the list it processes contains the parsed indented patterns
in the same order as the magic file, which caused the misdetection of
the mime type of those elf executables.

I fixed that by mirroring the list of patterns, the place where I'm
doing it may not be appropriate, but files in /bin are now properly
identified as executable files. »

Created attachment 25122 [details] [review]
my fix

Both patches are doing the same thing, they make sure the list of
patterns are stored in memory in the same order as they were in the
file. My version prepend each patterns to the list of already read
patterns, and the mirror that list, while the first patch attached to
that bug appends patterns to the list of already read patterns.
In real world, this shouldn't matter much from a performance point of
view, since the number of patterns for a given mime type will be
pretty small.

(the change in gnomevfs-info.c obviously doesn't have anything to do
with that bug)

I also filed
http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=264 about this
issue

Fixed upstream and in GTK+.  Sorry this took so long to get in.