I am having a similar problem with .jnlp files. In the past I have put them in the ZOOB and set the type by hand. Now, for management reasons I want to maintain them in the local file system. To make this work and get the mime type set right, I modified the LocalFS product adding entries in the _types dictionary and icon dictionary suitable for .jnlp files. For some unknown reason, this does not seem to work. The typemap displayed in the ZMI (generated from the _types dictionary) does not reflect the changes I made in the _types dictionary. Nor does the icon list. Are there other places in the system that need to be updated to add a mime type? BTW--it seems to me that mime types are mutable enough collect them in a single place rather than having them defined in multiple places as seems to be the case. On Wed, 18 Jun 2003, Rob Boyd wrote:

Hello,

I'm having problems with uploaded files not getting their content_type set to their correct mime type. Specifically, .jar and .jnlp files. I added entries to mimetypes.py for them (application/x-jar and application/x-java-jnlp-file) in mimetypes.types_map. I can now change the content_type property of an existing File object to these new types. However, when uploading a file, OFS.Image first correctly gets the content_type when init() calls get_content_type, but then manage_upload resets it to application/octet-stream. During this second round of get_content_type, it finds a content_type of application/octet-stream in the file's headers. Where does this come from? Not the file itself, but the File object? Can anyone shed light on this?