GNOME Bugzilla – Bug 340693
gnome-vfs2 incorrectly assigns a mime type to pdf files without a .pdf extension in the filename
Last modified: 2006-05-09 23:58:47 UTC
Please describe the problem: gnomevfs-info returns the incorrect mime type for pdf files without the .pdf extension. Instead of 'application/pdf' it gives 'application/octet-stream'. Both 'file' and 'kfile' return the correct mimetype, even if the file does not have the .pdf extension. This happens on my system (Fedora core 5, regular updates from rawhide, gnome-vfs2-2.14.1-4) for any pdf file. As a result, evince will not open a pdf file unless it has an explicit .pdf extension. Steps to reproduce: 1. Copy a pdf file, which we will call 'test.pdf'. Make sure the copy does not have the .pdf extension. We will call this copy 'test'. 2. Run gnomevfs-info on 'test.pdf'. The returned mime type is 'application/pdf'. 3. Run gnomevfs-info on 'test'. The returned mime type is 'application/octet-stream'. 4. For the sake of comparison, repeat steps 2 and 3 with the 'file' and 'kfile' commands. Actual results: gnomevfs-info identifies 'test.pdf' as 'application/pdf', and 'test' as 'application/octet-stream'. Expected results: Both files should be seen as 'application/pdf'. Does this happen every time? Yes. With any pdf file. Other information: This bug prevents evince from opening pdf files, unless they have the .pdf extension. This is a problem when web sites deliver a pdf file without the extension. As an example, try to open any pdf file from www.arXiv.org. Since the files are not delivered with the .pdf extension, they will only open once they have been renamed with the extension in place.
This same problem occurs for me. I have been developing a site using PHP which dynamically generates a PDF file which on Windows displays as expected. On Red Hat Fedora Core 5, the system automatically uses the evince application and falls over because the file extension is .php. The mime-type of the document is "application/pdf" which evince seems to ignore.
Evince doesn't exactly ignore the mime-type, it just never sees it. Firefox downloads it to a temp location and then calls evince like: evince file:///tmp/somefile.php, and so evince never has a chance to find out what the mime type the web server thinks it is. All the same, the gnome-vfs file typing for pdfs should be made more robust.
(In reply to comment #2) > Evince doesn't exactly ignore the mime-type, it just never sees it. Firefox > downloads it to a temp location and then calls evince like: > evince file:///tmp/somefile.php, and so evince never has a chance to find out > what the mime type the web server thinks it is. All the same, the gnome-vfs > file typing for pdfs should be made more robust. > But this is not relevant for the bug. It applies to *all* pdf files, not just those downloaded by firefox. So, if you have a file 'foo.pdf' in any local directory, running 'evince foo.pdf' from the command line will display it just fine. Now remove the .pdf extension and try to display the file with evince. Running 'evince foo' brings up evince with an error message that reads " Unable to open document Unhandled MIME type: 'application/octet-stream' " I agree that firefox could fix this problem by adding an appropriate extension to any files it downloads, based either on information from the server or its own internal mime-typing. But the problem is with gnome-vfs and needs to be fixed there.
Created attachment 65109 [details] [review] shared-mime-info patch Thanks for your bug report! This problem comes from the "shared-mime-info" package, which provides us with MIME data, and which provided multiple matching patterns causing failure if no extension is present. I just committed a fix, and I'm attaching the patch here in case distributors are interested in pushing this into their tarballs.
Resolving as NOTGNOME.
(In reply to comment #4) > Created an attachment (id=65109) [edit] > shared-mime-info patch > > Thanks for your bug report! > > This problem comes from the "shared-mime-info" package, which provides us with > MIME data, and which provided multiple matching patterns causing failure if no > extension is present. I just committed a fix, and I'm attaching the patch here > in case distributors are interested in pushing this into their tarballs. > Thanks for the quick resolution!
I tried applying this patch to my already installed /usr/share/mime/packages/freedesktop.org.xml, and after restarting gnome, it had no effect. gnomevfs-info still tells me that my extensionless pdf files are application/otcet-stream files. Looking at the contents of this patch, it seems to only modify the entries for matlab files and LaTeX files, and dosen't really have anything to do with PDF files. Do I need to do something else to get this patch to work, or is this, perhaps not right patch?
This patch does not seem relevant. Am I wrong? Not sure it is justified calling this bug NOTGNOME, since the proposed solution doesn't seem to work. Was the wrong patch attached? If this bug is NOTGNOME, then why do kfile and file both provide the correct MIME type, but not gnomevfs-info?
file does not use the shared mime info. i can't speak for KDE. This is definitely the correct solution. You need to run update-mime-database on the /usr/share/mime directory after applying the patch in order for it take effect. *** This bug has been marked as a duplicate of 339374 ***
My apologies; this is indeed the correct solution. I can confirm that patching the freedesktop.org.xml file as indicated, and then running update-mime-database, resolves the problem I originally reported. Thanks again for the quick resolution of this problem, even though it was NOTGNOME.