Description

If you're running the PHP application in strict mode and the file you wish to check for readability does not exist, an warning is given by PHP.
In my case this occurred if you validate a xyz@domain.net eMail address since in the folder "Hostname" is no file for .net domains.

A trivial fix would be:

instead of:

Comments

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-04-14T08:18:35.000+0000

Can you tell me whether or not we also should fix Zend_Cache::_isReadable ?
It seems Zend_Cache has same problem.

Posted by Gunter Spöcker (gunter) on 2008-04-14T08:49:14.000+0000

I would say so, since it is basically the same code.

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-04-14T19:34:38.000+0000

I think ZF-2701 has same trouble like as this.

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-04-23T10:37:21.000+0000

Resolved in SVN r2925

Posted by Darby Felton (darby) on 2008-04-23T12:47:31.000+0000

Reopening, since SVN r9295 should be reverted because {{fopen()}} is directed to utilize the {{include_path}}, whereas {{file_exists()}} does not use the {{include_path}}.

Posted by Jeffrey Sambells (jeffrey) on 2008-04-23T13:45:23.000+0000

Ya, r9295 breaks the PluginLoader: exception 'Zend_Loader_PluginLoader_Exception' with message 'Plugin by name Word_CamelCaseToDash was not found in the registry.'

Posted by julien PAULI (doctorrock83) on 2008-04-24T03:09:54.000+0000

Please, revert and see ZF-3170 as well

I have some more Zend_Loader tests to commit as well

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-04-24T10:05:54.000+0000

Thank you for mailing me and reverting, Darby.

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-05-02T10:00:19.000+0000

testing new code now

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-05-07T08:20:09.000+0000

I think the function will be as following.
Today, I tested with Zend_Loader_PluginLoader.
And I will try to test with other components.
I will be happy If you tell me any ideas :-)

Two notes: First, any solution that involves looping over paths in userland code will be rejected. These solutions have a tremendous performance impact, which is why the fopen() solution was chosen (the third argument to this function allows it search on the include_path -- but doing so in C is magnitudes faster than doing so in userland PHP).

Second, the fopen() call also has the error suppression operator; you will only see these errors in your error log. This is acceptable when it comes to E_STRICT standards -- the spirit of this rule refers to the messages that will be displayed when display_errors is on. This is one reason why error suppression is discouraged -- it should be used only for very, very good reasons. This is one such case, to our thinking.

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-10-06T06:03:07.000+0000

Hi, Matthew.

I thank you that you explain why fopen() should be selected than other ideas.

I think this issue should be closed as 'Won' t fix' , do you think?

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2008-11-03T05:06:45.000+0000

Hi, All.

I wondered why fopen() with at mark happens.
Because I did not find any warning in my tests with ver.1.6.1, 1.6.2, 1.5.3 and etc.

I understand what causes the warning, by talking about Simon on ZF-2900.
I recommend to look at that issue to solve this issue.

Posted by EV (evalder) on 2009-05-15T15:25:47.000+0000

"First, any solution that involves looping over paths in userland code will be rejected. These solutions have a tremendous performance impact, which is why the fopen() solution was chosen"

According to my tests, your fopen-based method is always 5-30% slower than my "looping over paths in userland code" method.

Var_Dump.php is part of PEAR, and was just added to test for existing files in include_path (assuming PEAR path is part of include_path).

You could try commenting out the call to set_include_path(), or calls to both methods using nonexisting file or existing file, just to check that the resulting times are always similar when given similar input. The two methods also provide the same actual results, of course.

Could you please change this now, or do you need more proof?

Posted by EV (evalder) on 2009-05-15T15:52:20.000+0000

Sorry, there was a bug in my method - empty input would return true, as is_readable would only check against the directories in include_path.
Adding the following line to the beginning of the method fixes the problem.
if ($filename === null || $filename === false || $filename === '' || !is_scalar($filename)) return false;

Actually, I asked that this issue was un-duplicated, ie. remove the duplicate tag for this issue. I also mentioned that I would post a new bug instead, implying that re-opening this one would not be necessary.

You may close this again unless there were other reasons than my comment in ZF-2900.

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2009-05-28T02:35:31.000+0000

If you think it is not duplicated issue, I would be out of ability to close this.
change into unassign.

Posted by Thomas Weidner (thomas) on 2009-06-03T04:04:29.000+0000

Removed link to ZF-2900.

Closed issue again as the mentioned code is not reproducable and already fixed within the actual release.