Issue 4969: mimetypes on Windows should read MIME database from registry (w/patch) - Python tracker

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: fhamand, ggenellina, ocean-city, pitrou, tercero12
Priority: normal Keywords: patch

Created on 2009-01-17 08:58 by ggenellina, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
mimetypes.diff ggenellina, 2009-11-15 08:55 Version 2
Messages (6)
msg80007 - (view) Author: Gabriel Genellina (ggenellina) Date: 2009-01-17 08:58
The mimetypes module has a built-in default database, and, in addition, 
reads mime.types files from a list of standard places (/etc/mime.types 
by example)
On Windows, those files usually don't even present; MIME information is 
stored in the registry instead. Until now, the mimetypes module just 
ignored those settings; this patch adds support for reading the MIME 
database from the Windows registry.
msg94875 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-04 01:26
A couple of points:
- if the method is Windows-specific, I don't think it shouldn't bear a
name as generic as "read_registry()". There are "registries" on other
systems.
- the method should probably raise early on non-Windows systems (raise
NotImplementedError?)
- please fix the coding style; don't collapse a "try", "except" or
"finally" and the following statement on a single line
- in the tests, rather than defining an empty test case on non-Windows
systems, make the tests skip (for example, call self.skipTest()
msg95279 - (view) Author: Gabriel Genellina (ggenellina) Date: 2009-11-15 08:55
A new patch taking into account M. Pitrou comments:

- name changed to read_windows_registry()
- read_windows_registry() does nothing on non-Windows platforms; same 
as read_mime_types(filename) when the file does not exist.
- I hope the coding style is acceptable now
- the test is skipped on non-Windows platforms
- documentation updated
- documentation for MimeTypes.guess_all_extensions was missing; I 
added it although it isn't directly related to this issue.
msg95291 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-15 14:06
Thank you, the patch looks ok to me.
msg95294 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-15 14:26
Committed in r76306 and r76307, closing.
msg185039 - (view) Author: Frank Hamand (fhamand) Date: 2013-03-23 12:05
From msg172531 in issue10551:

"You see, "MIME\Database\Content Type" in the Windows registry is a mime type -> file extension mapping, *not the other way around*. But read_windows_registry() tries to use it as a file extension -> mime type mapping, and bad things happen, because there are multiple mime types for certain file extensions."

This "enhancement" has basically broken the mimetypes module on windows,

e.g. On my system (windows 7 64 bit, python 3.3)
>>> mimetypes.guess_type('foo.png')
('image/x-png', None)
>>> mimetypes.guess_type('foo.jpg')
('image/pjpeg', None)

The expected results are image/png and image/jpeg

I'm having to work around this by calling mimetypes.init(files=[]) immediately after importing mimetypes to prevent it reading from the registry