Hi Melissa -
For some reason, the unix "file" command is giving unexpected mime types for certain files.
For now, if you replace your _sanity_check_mime_type method in carl_util/basic/mime_types.php with the following, it should fix the problem (or do an svn update tomorrow), but I'm looking at a better long term solution than a list of cleanup rules...
/**
* Fixes stupid results from file(1).
*
* On some systems, the file command can return some results that we really
* don't want. For example, some assume that the presence of a C-style comment
* start token (/*) means that the file is a C source or header file
* (text/x-c). This is bad when it is given (for example) a CSS file that has
* any comments in it.
*
* @param string $file_extension
* @param string $mime_type
* @return string a maybe-fixed MIME type
* @access private
*/
function _sanity_check_mime_type($file_extension, $mime_type)
{
if ($file_extension == 'css') {
// We're just going to assume it's CSS.
$m = array();
return (preg_match('/;\s*charset=(\S+)/', $mime_type, $m))
? "text/css; charset={$m[1]}"
: "text/css";
}
if ($file_extension == 'xls') {
// We're just going to assume it's Excel.
return "application/excel";
}
return $mime_type;
}
You will need to re-upload those excel files that you recently
uploaded, because they have the wrong mime type in the entity.
Alternatively, you could use phpMyAdmin or something to change the
mime_type field for assets with the file_type .xls to application/excel.
Excel files uploaded in the past (more than a couple weeks ago) should
be fine, as the changes to mime type detection are relatively recent in the nightly builds.
Nate