not recognizing the ZIP mime-type (application/zip) for docx file

Sounds like mimedetect isn't working properly to identify the file type. Have you set up the "file" command at admin/settings/mimedetect? It would probably help identify the problem if you could upload the file to drupal.org or if it's a large file, make it available for download elsewhere.

yeah i think the magic library we ship is kind of limited. i'm not sure how to write a signature for it for zip files. might be better to use the system's if available. there's an issue for making the mime file customizable.

It appears that fileinfo and file relies on a magic file. If this file is not current, this module will not work.

From the command line type "file filename" and it should something other than zip.

This patch does two things: 1) Updates our magic file so that it returns "application/zip" instead of "application/x-zip" so that it matches file_get_mimetype() and 2) Makes mimedetect actually use the magic file. Right now it looks like we're shipping mimedetect with a magic file, but not actually using it anywhere.

Right now it looks like we're shipping mimedetect with a magic file, but not actually using it anywhere.

Definitely a bug but technically we are using it with the PHP mimedetech extension, just not the file command...

technically we are using it with the PHP mimedetech extension, just not the file command

Ah, right I hadn't seen that reference. It'd definitely be handy to use the same magic file in both places.

minor tweak. committed to HEAD, D6 and D5.

Works great, thanks drewish.

I am experiencing the same issue with ODT and RTF files.
Let me know if I should open a separate issue for this.

The selected file test.odt could not be uploaded. The file contents (application/zip) do not match its extension (odt).

The selected file test.rtf could not be uploaded. The file contents (text/rtf) do not match its extension (rtf).

I tested this with files created in OpenOffice 3.1.0 and NeoOffice NeoOffice 3.0.1.

Running Drupal 6.15, FileField 6.x-3.2, MimeDetect 6.x-1.2.

Sorry guys, this should be clear from the discussions above, but I'm not sure what to do next (as possibly weka feels as well?)...

Right now (6.x-1.2) mimedetect's config interface says:
"The MimeDetect module is using PHP's fileinfo extension to detect MIME types. There are no settings for the extension."

I can get into a webmin interface and see some settings for the php.ini file, but nothing looks like a fileinfo.

I've posted my situation with kml files on filefield's queue at: http://drupal.org/node/775188

Where/how to edit what?

Hello. Quicksketch is back on the queue after drupalcon.SF and reckons the problem is my magic file (http://drupal.org/node/775188).

Looked in the mime.magic file and could not find a reference to kml or kmz files. Searched extensively and found a reference that seems to work.

Added this line under Local Stuff in modules/mimdetect/mime.magic:

#KML Files
>>23	search/400	\<kml	text/xml 

CLARIFICATION: not trying to pollute this thread, but my issue seems to be the same, just with a different filetype.

And a further note: I'm not sure why this whole thing doesn't degrade nicely back to Apache. In my case the mimetype exists in the httpd.conf file. I don't suppose there's any way to use something like an automated drush command to suck the contents of the local MimeMagicFile into the local mimedetect/mime.magic file? Or, more practically, allowing users to point to a symbolic link to the Apache file, and asking MimeDetect to *also* parse it...?

FWIW, my clever insertion above did allow me to upload KML files, but on the next run of update.php the PHP File Extension complained:

Fileinfo could not load the magic file. It could be corrupted. Try reinstalling the magic file distributed with the MimeDetect module.

Yep: sure would be nice to actually fix this properly. Anyone have an idea about the required syntax, or is it a more profound issue?

echo repeat echo ... can I help answer the question: what is the recommended way to get kml files uploaded to a Drupal site that has chosen to also run this fine module?

thanks.

Another problem I encounter with using the mime application/zip to identify the ZIP file is that it only identifies the compressed file, not archive’s contents.

I am getting same error for rar and gzip files, to fix it I changed magic.mime file as follows:

0	string		Rar!		application/x-rar

to

0	string		Rar!		application/rar

and it now it works...
Thanks,

KH

#21, thanks, solved my issue too.

I'm running into the same issue with a docx file -- I've got a site taking admission applications to a graduate program, and I'm getting the message "The selected file ... could not be uploaded. The file contents (application/zip) do not match its extension (docx)."

Doc files and pdfs both work in the form (which is a custom module) without problems. Docx files worked several months ago, before I installed mimedetect, which I added to enable listhandler and mailhandler to import attached files. Docx files do work with some other parts of the site, like webforms or just attaching files to a page. The only difference I can figure out is that with the admission application, the file upload is a cck field and uses filefield, which in turn is callling mimedetect.

Fixing this is a little over my programming head. Any advice on how to proceed?

Thanks!

Resolved, at least temporarily and for our web host's magic file, by adding the following line to the array of additional mimetypes in mimedetect.module:
'docx' => 'application/vnd.openxmlformats',

And by commenting out the attempt to use fileinfo first, right below that.

Closing this as outdated, feel free to re-open if you're still looking for a solution and waiting for appropriate assistance.