Description: ------------ There are three issues. 1. _handleDetection returns an error message when it should return false. 2. When an autoDetect method has been unable to determine the file type it should fall back on another method instead. 3. There is no way to specify the fileinfo database you wish to use. I had this issue before and solved it by writing my own function, which I superseded by using this PEAR package. However, this PEAR package does not tackle the issues I originally faced. I will attach my function which also outlines the issue, which perhaps you can incorporate into the package. Test script: --------------- <?php require_once 'MIME/Type.php'; $filename = '/path/to/some/file.jpg'; $type = MIME_Type::autoDetect($filename); echo $type; //returns Sorry, couldn't determine file type. ?> Expected result: ---------------- $type returns false Actual result: -------------- $type returns "Sorry, couldn't determine file type."

Re: _handleDetection, PEAR_Error objects are instantiated and returned - that's fairly consistent throughout the package. A cursory review of the source shows that it is invoking raiseError() appropriately. Perhaps there's something amiss with your configuration if it appears to be returning raw strings require_once 'MIME/Type.php'; $filename = '/path/to/some/file.jpg'; $type = MIME_Type::autoDetect($filename); if (PEAR::isError($type)) { // unable to determine mime type. } else { echo $type; }

I agree on the other parts - it would be great to split off the assorted detection methods into simple drivers. That way James could just build a massive array of them and iterate through; or control the sort order.

Let me correct that: _handleDetection returns an error message when it should return a PEAR_Error object. I am unaware of any configuration issues. That sounds like a good idea Daniel, I feel more can very easily be done to automatically detect/determine the file type.

I don't find the issue with _handleDetection. There is no string returned.

> 2. When an autoDetect method has been unable to determine the file type > it should fall back on another method instead. It does that already for finfo_file and mime_content_type. Only System_Command with "_handleDetection" doesn't do it, so it does not fall back to MIME_Type_Extension.

> 2. When an autoDetect method has been unable to determine the > file type it should fall back on another method instead. The system_command problem has been fixed in git master.

The configurable magic file database is implemented in git master. All problems of this bug should be solved now.

http://code.google.com/p/hm2k/source/browse/trunk/code/shell/peargit [root@blade ~]# ./peargit MIME_Type [peargit] Git Clone... Cloning into MIME_Type... remote: Counting objects: 201, done. remote: Compressing objects: 100% (130/130), done. remote: Total 201 (delta 82), reused 178 (delta 59) Receiving objects: 100% (201/201), 39.55 KiB, done. Resolving deltas: 100% (82/82), done. [peargit] Make PEAR package... Analyzing MIME/Type.php Analyzing MIME/Type/Extension.php Analyzing MIME/Type/Parameter.php Warning: Channel validator warning: field "date" - Release Date "2010-10-25" is not today Package MIME_Type-1.2.1.tgz done [peargit] Uninstall PEAR package... pear/MIME_Type not installed [peargit] Install PEAR package... ERROR: bad md5sum for file /usr/share/pear/MIME/Type.php [peargit] Cleanup... [peargit] Done! --- MIME_Type didn't install, but that's a separate issue. I cloned it manually instead, here's what I tested: <?php require_once 'MIME/Type.php'; $url='http://www.php.net/manual/ja/images/21009b70229598c6a80eef8b45bf282b -imagecopyresampled_2.jpg'; $file=sys_get_temp_dir().DIRECTORY_SEPARATOR.basename($url); copy($url,$file); $type = MIME_Type::autoDetect($file); unlink($file); echo $type; ?> The result was as expected: "image/jpeg". I tried various URLs all which produced the expected results. Thanks.