GNOME Bugzilla – Bug 623861
Content-Type not reported correctly for JPG named "attachment.tif"
Last modified: 2018-09-21 17:05:06 UTC
Am getting the following output for the attached file: display name: attachment.tif edit name: attachment.tif name: attachment.tif type: regular size: 120583 attributes: standard::type: 1 standard::name: attachment.tif standard::display-name: attachment.tif standard::edit-name: attachment.tif standard::copy-name: attachment.tif standard::icon: image-tiff, gnome-mime-image-tiff, image-x-generic standard::content-type: image/tiff standard::fast-content-type: image/tiff standard::size: 120583 standard::allocated-size: 122880 etag::value: 1278369194:574208 id::file: l64771:3757 id::filesystem: l64771 access::can-read: TRUE access::can-write: TRUE access::can-execute: FALSE access::can-delete: TRUE access::can-trash: TRUE access::can-rename: TRUE time::modified: 1278369194 time::modified-usec: 574208 time::access: 1278608980 time::access-usec: 870577 time::changed: 1278608979 time::changed-usec: 705579 unix::device: 64771 unix::inode: 3757 unix::mode: 33204 unix::nlink: 1 unix::uid: 500 unix::gid: 500 unix::rdev: 0 unix::block-size: 4096 unix::blocks: 240 owner::user: ruben owner::user-real: Ruben Vermeersch owner::group: ruben thumbnail::path: /home/ruben/.thumbnails/normal/fdc90503c4cd192a3fd33567e71c9fbf.png selinux::context: unconfined_u:object_r:user_home_t:s0 xattr-sys::security.selinux: unconfined_u:object_r:user_home_t:s0 metadata::icon-scale: 1 metadata::nautilus-icon-position: 64,462 metadata::nautilus-icon-position-timestamp: 1278608980 Whereas: $ file -ib attachment.tif image/jpeg; charset=binary This breaks mime-based loading in F-Spot.
Created attachment 165495 [details] JPG named "attachment.tif"
Huh, that's not a bug in gvfs, or in GIO. If you expect such broken files to be loaded (where the filename doesn't match the type of data to load), you'll need to guess the mime-type from the data, and only the data, not using the file suffix.
Isn't that what the content-type property is for? If I read the manual correctly: "The fast content type isn't as reliable as the regular one, as it only uses the filename to guess it, but it is faster to calculate than the regular content type." So I'd guess the normal content-type property will use something more than just the filename, no? If not, how can I do reliable content-based mime-type detection using GIO? And what is the actual difference between content-type and fast-content-type?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/152.