[Zope-CMF] Fwd: [CMF] 281/ 1 Request "FSFile content_type weakness"

[Jens Vagelpohl]

>> I believe correcting the computation in FSFile._readFile to consider
>> the .metadata file first should do the trick.
>
> You got the problematic case?
>
>   There is no ".metadata" file.
>
>   The content_type was guessed in "_readFile".
>
>   You change the file; in development mode "_readFile"
>   is executed again. It probably should reguess the content_type
>   (based on the new content).

I have a hard time coming up with a scenario where a file on the file 
system changes content type but retains exactly the same file name and 
extension...  I see your point, but I can't think of a way to provoke 
that outcome.

Anyhow, this would be a quick patch to make sure that the content type 
value as found in a .metadata file is treated specially by stuffing it 
into a new attribute:

Index: FSFile.py
===================================================================
RCS file: /cvs-repository/Products/CMFCore/FSFile.py,v
retrieving revision 1.12
diff -r1.12 FSFile.py
52a53,56
 >         self._metadata_content_type = None
 >
 >         if properties is not None:
 >             self._metadata_content_type = 
properties.get('content_type', None)
62,67c66,69
<         # Consult self.content_type first, this is either
<         # the default (unknown/unknown) or it got a value from a
<         # .metadata file
<         default_type = 'unknown/unknown'
<         if getattr(self, 'content_type', default_type) != 
default_type:
<             return self.content_type
---
 >         # If a value was found in the .metadata file it will get
 >         # top priority and will be returned immediately.
 >         if getattr(self, '_metadata_content_type', None) is not None:
 >             return self._metadata_content_type

jens