User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Filed against Thunar-0.9.0-2.fc8 as built for Fedora 8. This is a bug I've seen as a long term issue back to xffm in 2004. The file type icon for a file will change based on its extension but is incorrect for the actual file. When the extension is not present at all the correct icon is shown and filetype is displayed in the file properties. For instance naming an RPM file as: package.rpm <- correct icon shown package.rp <- incorrect icon shown (assumes file is type realpix and displays image icon) package.r <- correct icon shown package <- correct icon shown In brief, if the filename extension is present and matches something 'known' it is trusted as correct despite the fact that Thunar knows the filetype without an extension. The extension should not be prioritized if the filetype can be detected without it. For reference, nautilus 2.20.0-7.fc8 does not mistake the filetype based on its extension in this way; the correct icon and filetype in properties is shown even with the .rp extension. This is also filed downstream (though it got lost for awhile): https://bugzilla.redhat.com/show_bug.cgi?id=136448 Reproducible: Always Steps to Reproduce: -Rename file with incorrect extension for the filetype Actual Results: -Incorrect icon is shown if the extension matches another 'known filetype' Expected Results: -Correct file type icon should be shown even with incorrect extension
This is not simply an icon issue. When a package with the .rp extension is double clicked (showing the realpix image icon) Thunar attempts to open that file with VLC media player (seems to be the handler for that format on my system). This is poor behavior to open an RPM package archive with a media app. When no extension is there or the correct extension is there then the correct RPM package handler is opened by Thunar.
I fail to see the bug here... what you describe is the expected behavior and is consistent with the agreed mime standard (that said, Gnome and KDE behave the same). There's one case where Thunar differs from Gnome: Magic Rules with a priority of 80 or higher aren't checked prior to the extension rules, so this might explain why Nautilus does detect a different mime type. Once both Gnome and Xfce use GVfs, these differences will be gone. On a side note: It would indeed be possible to do content sniffing on each and every file, but that would (a) be rather confusing to the user (users expect that a file named whatever.txt is detected as plaintext file, even tho it may containt XML or HTML, and (b) VERY inefficient.
Very well, as long as it is known and intended behavior its not a bug at present. It is however unfortunate that throwback from dos 8.3 naming restraints (where the extension was the only type identifier) still plagues what 'users expect'. A file can be opened by whatever application and interpreted as any type you desire, but it should not be misidentified by your interface to the file system (the file manager). This is apparently an issue for another discussion elsewhere, but I hope then when Thunar is using GVfs this does disappear as you suggest it should.