i would like to have more details about this, thanks:
Hi,
What is that new mimetype you registered?
Can you please share its definition?
If it tries to assign the .png extensions to some other mimetype than image/png, then of course that will confuse the mime resolution.
hello and thanks for the answer.
the example mime is:
<mime-type type="audio/x-example">
<magic>
<match type="big16" value="0xffff" offset="0:63"/>
</magic>
<glob pattern="*.example"/>
</mime-type>
where value, offset and glob pattern are just example data
now, having this registered (that has nothing to do with png mime) if i try to open with gdk_pixbuf_new_from_file_at_scale a dummy.png image file that (accidentally) has 0xffff in first 64 bytes i will get error: gi.repository.GLib.GError: gdk-pixbuf-error-quark: Couldn’t recognize the image file format for file "dummy.png"
seems the glob pattern isn’t take in account, while running xdg-mime query filetype dummy.png i will correctly get audio/x-example type since <glob pattern="*.example"/> is respected
I’m not 100% sure what’s going on here, but I know in GLib there are 2 ways to get a file content type:
- a “fast” way, relying only on file extension
- a “normal” way, that will perform more checks
I suppose GdkPixbuf goes for the normal way, for better chances to properly recognize the mimetype of media files, in which case the magic may take precedence.
I’m not expert of the freedesktop spec about mimetype, maybe there are more info on their website, but aynway I’ve the feeling 0xffff is way too generic to be reliably used as magic pattern for type detection.
hello and thanks for the answer. 0xfff as said its only an example value, but i’ve already encountered more than one image file, in the real world, that has matching with a 32bit value (as a Legit magic) of a non-image mime magic, so the point it is not about likelihood but about how the matching is behaving. i expect that if xdg-mime says me the file im querying it is a not a png, it should be the same for GdkPixbuf too. if the matching relies only on magic ignoring glob pattern then there are so many real world cases that have the same issue with GdkPixbuf
I looked at the specs, actually the checking order is not enforced, so may depend on implementations. There is no guarantee gdk-pixbuf and xdg-mime work the same way.
Especially, for loading media files, it make sense that a valid magic is ensured, as extra safety check, before feeding the data to the decoders.
On gdk-pixbuf side, I checked the source code and confirm the magic check has priority over the globs.
And the magic check itself will return the mime with highest priority.
IMHO the real issue here is that the mime database is abused by some apps that declare very generic magics with too high priority (the default is 50 if undefined).
Gdk-pixbuf is on the safe side by refusing to load files that report themselves as something different than expected.
thanks for ur answer. the point here is why a non-png (non-image) format mime-db entry should prevent GdkPixbuf for loading a legit png? if GdkPixbuf wants to be safe then it should simply allow only a subset of well-known mime image formats (like png, jpg, bmp, etc) to match against, if not it is unrespectful of mime db and this not appears to me not a safe choice since leds to so many breaks in the real world, isn’t it?
Yeah, that situation is not ideal…
Ideally GdkPixbuf could do a first match with the globs, and if found then confirm by checking the corresponding magic too. But I’m not sure there are mime APIs to do that… I need to have a look.
But is it really GdkPixbuf’s job (or any other app) to make hacks against broken mime databases?
thanks for ur reply. the wrong assumption here is that the mime db is “broken”: a perfectly legit non-image mime db entry with default 50 priority can break GdkPixbuf as per gdk_pixbuf_new_from_file_at_scale currently works
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.