I have seen this as well. Mantis uses fileinfo , but if that information is not available it reads the data from the mantis_bug_file_table . That data, in turn, is reported by the browser when uploaded. What kind of data do you have for docx/docm etc files in the mantis_bug_file_table.file_type column?

Hello,

Thank you for your quick response.
For a docx file, I have this:
application/vnd.openxmlformats-officedocument.wordprocessingml.document

For a msg file, I have this:
application/octet-stream

So it seems that fileinfo is used because the HTTP headers sent contain a different value than what is in the database.

Is there a way to force not using fileinfo? Or better yet, a way to teach fileinfo about new file formats?

Maybe helps 0011728

Thanks, but I can download just fine, it's the Content-type that is wrong.
I could change the "magic.db" file but I'd rather have the Apache configuration be used as I know this one is much more precise than just the guessing done by fileinfo

There seems to be now way of retrieving these MIME mappings ( apart from parsing the configuration files manually, but I'd rather not go there ) . Do you know of any way to retrieve these mappings ? Bonus points for working across multiple servers...

Also have this bug - highly annoying (and kind of stupid... why oh why did anyone think it was a good idea not include an option to ignore this and use apache built in mime handling? - it works perfectly well).

Any ideas of a fix?

AFAIK you can't tell the web server to send detect the content type of a stream of bytes.

If you have a way of doing that, let me know or submit a pull request and I'll apply the fix.

Maybe this could help:
http://www.php.net/manual/fr/function.mime-content-type.php#94279

Rombert, its possible I'm confused about how apache handles files. It looks at the extention as far as I'm aware?

So... I upload a xlsx file. Apache sees its a .xlsx, this matches in /etc/mime.types and so it sends it as a "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

However, from what I gather mantis instead sees the file, ignores apache and inspects the file directly. It sees it appears to be a zip file and so when the download is attempted it sends it as application/zip. I presume this is due to some magic value.

My fix is, stop using mantis logic to work out what to send the file as, simply send it as whatever Apache wants to send it as, using /etc/mime.types - if the link on the bug was directly to the attachment (and the attachment was stored in filestore, not db), I believe this would download correctly. However I don't have a test setup of mantis to try this with.

I maybe be completely lost here, as I've already said, because I'm not a developer. This is what I've gained from reading random ramblings online about what people say worked for them.

(In reply to comment 0013439:0030164)

Maybe this could help:
http://www.php.net/manual/fr/function.mime-content-type.php#94279

Thanks for the pointer. That is a workaround indeed, but it has a couple of disadvantages:

1. It only works with Apache
2. It accesses the configuration file directly, and its location is non-standard

I would not see this as a definite solution for this bug.

(In reply to comment 0013439:0030165)

My fix is, stop using mantis logic to work out what to send the file as, simply
send it as whatever Apache wants to send it as, using /etc/mime.types - if the
link on the bug was directly to the attachment (and the attachment was stored in
filestore, not db), I believe this would download correctly. However I don't
have a test setup of mantis to try this with.

Storing file attachments in the database is one complication - we can't ask Apache what the content type for that file is. Another complication is the one mentioned in my previous reply - there is no standard way of asking a web server for a content type by extension. PHP runs on multiple web servers and it would be a shame to tie functionality to Apache, as this is a pretty annoying bug.

Somewhere to enable user editing of certain extensions then.

A file for mantis which says "if the extension is $X, the file is of type $y". You'd basically be replicating the Apache functionality, but it'd be portable. Also make this optional so you can use either/or the magic file value, or this.

Or, option on the download page, to download "as filetype $y" which would then set the download type.

(In reply to comment 0013439:0030168)

Somewhere to enable user editing of certain extensions then.

That's one possibility, yes. That should be an override rather than a fallback I think.

Fixed, but no changeset attached?
Where are the changes so that I can test them?

(In reply to comment 0013439:0030514)

Fixed, but no changeset attached?
Where are the changes so that I can test them?

https://github.com/mantisbt/mantisbt/commit/d6b959201f080016304cf6877399a72d7ade1b18 is for the 1.2 branch. You can either apply that patch individually or pick up the latest code from github, master-1.2 branch.

Ah great, thanks, looks just fine.

Just tested it, it works very well.
I would have added the following default override too:

'msg' => 'application/vnd.ms-outlook'

But it's easy to add it inside my config_inc.php file, so it's not a major issue that it is not in the default array.

Thanks a lot for your help

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch