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

Request #18328 Proper default for cacheDir
Submitted: 2011-03-02 15:57 UTC
From: saltwaterc Assigned: tacker
Status: Closed Package: Cache_Lite (version 1.7.8)
PHP Version: 5.3.5 OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 19 - 18 = ?

 
 [2011-03-02 15:57 UTC] saltwaterc (?tefan Rusu)
Description: ------------ cacheDir makes the blatant assumption that /tmp/ is the proper path for creating the cache files. However, there are applications (notably the SURBL class from Net_DNSBL) which rely onto the default value. This has a couple of implications: - Cache_Lite doesn't work by default under Windows - Cache_Lite doesn't support a proper virtualhost environment where each virtualhost is separated by filesystem permissions and open_basedir restrictions. However, since PHP 5.2.1, a new function is supported by the PHP API: sys_get_temp_dir() which returns the proper temporary directory as defined by the operating system (the $TMPDIR environment variable under Unices or %TMP% under Windows). sys_get_temp_dir() fixes both issues. It enables Windows users to have a proper temporary path (C:\Windows\TEMP for example if PHP is integrated with IIS over FastCGI). It also enables the open_basedir restrictions to be granular, per virtualhost, if a systems administrator decides to use a restrictive path by defining a $TMPDIR / %TMP% environment variable while that path is added to the open_basedir configuration directive. The Cache_Lite clients should not care where the files are stored if they don't define proper defaults, but Cache_Lite should use the newer PHP API if it is available in order to provide a clean and safe cache path. We patched our own installation by adding these lines to the Cache_Lite constructor, before the $options array is iterated: if(empty($options['cacheDir']) and function_exists('sys_get_temp_dir')) { $options['cacheDir'] = sys_get_temp_dir().DIRECTORY_SEPARATOR; } Test script: --------------- <?php // set require_once 'Cache/Lite.php'; $cache = new Cache_Lite; $cache->save('stuff', '123'); <?php // get require_once 'Cache/Lite.php'; $cache = new Cache_Lite; var_dump($cache->get('123')); Expected result: ---------------- :~$ php cache-set.php :~$ php cache-get.php string(5) "stuff" Actual result: -------------- Under Windows: > php cache-set.php > php cache-get.php bool(false) Under Linux with open_basedir enabled (production setup): :~$ php cache-set.php throws an open_basedir restriction in effect error

Comments

 [2011-03-02 16:11 UTC] tacker (Markus Tacker)
-Status: Open +Status: Analyzed -Type: Bug +Type: Feature/Change Request
Hoi Stefan, thanks for your elaboration. As the directory can be configured and the examples in the docs always include the configured cacheDir this is merely a usage problem not a bug. So it's up to the use to define a working cache folder. Anyway, I am going to add your change as this imposes no harm.
 [2011-03-02 17:13 UTC] tacker (Markus Tacker)
-Status: Analyzed +Status: Closed -Assigned To: +Assigned To: tacker
Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at http://pear.php.net/get/
 [2011-03-02 22:06 UTC] saltwaterc (?tefan Rusu)
Hello, Thanks for your support. It's quite irrelevant how the issue is called (bug / feature request). The important thing is that now it works as expected. I am confirming that this fixes the SURBL broken behavior under our production setup. It may also fix other libraries depending on Cache_Lite if they rely on cacheDir the same way as the SURBL class does. Also thanks for your flexibility. Other developers may simply return: it's the ${other}'s fault, let the ${other} fix it. When the previous statement becomes a vicious circle, we, the users of that product as a whole, have loads of fun fixing issues that should not exist. Thanking you for not being that kind of developer. Regards, ?tefan