Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.10.0dev1

Bug #11317 Registry::hasWriteAccess loops endless
Submitted: 2007-06-14 13:54 UTC
From: ralfbecker Assigned: cellog
Status: Closed Package: PEAR (version 1.6.0)
PHP Version: Irrelevant OS: Linux
Roadmaps: 1.6.1    

 [2007-06-14 13:54 UTC] ralfbecker (Ralf Becker)
Description: ------------ If for some reason the Registry::install_dir does not exist and the user (webserver) has no write-access to any part of that path, Registry::hasWriteAccess will loop endless. function hasWriteAccess() { if (!file_exists($this->install_dir)) { $dir = $this->install_dir; while ($dir && $dir != '.') { $dir = dirname($dir); // cd .. if ($dir != '.' && file_exists($dir)) { if (is_writeable($dir)) { return true; } else { return false; } } if ($dir == '/') break; } return false; } return is_writeable($this->install_dir); } As dirname($dir='/') returns again '/'. The fix shown above, breaks that endless loop. Ralf


 [2007-06-16 13:31 UTC] cellog (Greg Beaver)
Hold on - the code should exit because file_exists('/') is true. Could you verify the output of this script: <?php var_dump(file_exists('/')); ?> is bool(true) I can't reproduce the behavior you describe in any circumstance. Perhaps there is some critical piece of information missing? What path was install_dir? Which directories exist?
 [2007-06-16 13:33 UTC] cellog (Greg Beaver)
aha - you have safe_mode active, don't you? file_exists() would return false on / in this case.
 [2007-06-16 13:42 UTC] cellog (Greg Beaver)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.
 [2007-06-18 02:22 UTC] ralfbecker (Ralf Becker)
Hi, the site is NOT using safe_mode, only open_basedir, which only includes the docroot and the pear directory. As a workaround I check now in our installer if the install-dir exists and fallback on our old mode of checking a pear package is available by trying to include it. Unfortunately this does not give the version numbers, I need for dependency checks. But calling the pear registry goes in that endless loop. You can have a look at the code at: search for get_installed_pear_packages() I'm not considering this problem fixed, as I have no influence on the wrong configuration. I personally think it's a bug, that this misconfiguration causes the pear registry class to go in an endless loop. Please re-consider your decision not to fix it and to close this bug. Thanks for your help anyway :-) Ralf
 [2007-06-18 08:01 UTC] cellog (Greg Beaver)
?? Closed = fixed Bogus = not a bug. This has been fixed in cvs