Description of problem: As for bug #189086 in relation to comment #1, I would like to reassign it to gnome-vfs (but I could not), so I report directly. Version-Release number of selected component (if applicable): 2.14.1-1.fc5.2 How reproducible: Well, I would say always. Steps to Reproduce: 1. See the above mentioned bug and related comment or 2. Take a pdf file, let's say "mydoc.pdf". 3. Rename (or copy) without the extension, for example as "mydoc". 4. Try to open from nautilus. Actual results: An error is reported: Couldn't display "/home/red/tmp/Incoming/mydoc". Expected results: The usual PDF application is used to open the file, usually "evince" or "xpdf". Additional info: The file /etc/gnome-vfs-mime-magic should containt the information necessary to open a file using the magic number. Specifically, it containts the PDF type, so there is no reason, AFAIK, for the error.
I forgot something. If we look at the file properties, we see it is reported: MIME type: application/octet-stream as for the error in firefox.
This bug also appears to cause bug #186241. I can verify that magic numbers aren't being used by commenting out a line in /usr/share/mime/globs (say image/jpeg: *.jpg) and gnomevfs-info will report all image files as "application/octet-stream".
In the PDF case, see also bug #188584.
Created attachment 131413 [details] Magic file from FC-5 that doesn't recognise PDFs Magic file from FC-5 in which evince doesn't recognise PDFs.
Created attachment 131414 [details] Magic file from FC-4 in which evince does recognise PDFs If I use this magic file (from my FC-4 installation) in place of the original FC-5 magic file, evince correctly recognises the file as a PDF even without the .pdf extension.
(In reply to comment #4) > Magic file from FC-5 in which evince doesn't recognise PDFs. ...if the PDF doesn't have the .pdf extension.
These files are from /usr/share/mime/magic which is generated by the shared-mime-info package.
Bumping the priority on the application/pdf to 60 in /usr/share/mime/magic as described in this upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=6577 fixed this for me.
I'm puzzled. The "magic" stuff is declared twice, once in /etc/gnome-vfs-mime-magic, which comes from "gnome-mime-data", and once in /usr/share/mime/magic, which comes (generated) from "shared-mime-info". I'm really curious to know what's the reason... bye
Created attachment 131487 [details] patch against freedesktop.org.xml.in: set priorities for "%" matches properly With this patch, the priorities for the "%" matches for text/x-matlab and text/x-tex are set to 10 so that more specific matches like "%PDF-" have precedence over them. It contains the changes of this cvs commit: http://webcvs.freedesktop.org/mime/shared-mime-info/freedesktop.org.xml.in?r1=1.138&r2=1.139
Created attachment 131489 [details] patch for spec file: apply shared-mime-info-0.17-tex-matlab.patch This patch modifies shared-mime-info.spec so that the patch attached with comment #10 is applied during build. I think it would be a good idea to add the patch to the rpm because it's pretty simple and it fixes a really annoying bug. Of course, an alternative would be to ship a cvs snapshot or to ask the upstream maintainers to make a new release (the latest release dates from 2006-03-14).
With the latest "shared-mime-info-0.17-1.fc5.2" from updates, the fix, from mainstream, is included. I checked nautilus and firefox, and both operates properly with pdf files without ".pdf" extension. I guess this item can closed.
*** Bug 186241 has been marked as a duplicate of this bug. ***
*** Bug 195471 has been marked as a duplicate of this bug. ***