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

Request #13693 warning function.unlink: No such file or directory
Submitted: 2008-04-16 08:23 UTC
From: remicollet Assigned: tacker
Status: Closed Package: Cache_Lite (version 1.7.3)
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  


 [2008-04-16 08:23 UTC] remicollet (Remi Collet)
Description: ------------ This occurs in /usr/share/pear/Cache/Lite.php line 577 There is also in the raiseError call. Test script: --------------- Sorry, don't have one, only the log from a big application using this extension. Expected result: ---------------- no warning Actual result: -------------- Warning: unlink(/var/lib/glpi/files3/_cache/cache_a/cache_ac/cache_1da1f4575fb79408d13aa153af3f44de_e02a561417373c7a0bc3d62df17ebce3) function.unlink: No such file or directory /usr/share/pear/Cache/Lite.php line 577 Runtime Notice: Non-static method PEAR::raiseError() should not be called statically, assuming $this from incompatible context /usr/share/pear/Cache/Lite.php line537 Runtime Notice: Non-static method PEAR::getStaticProperty() should not be called statically, assuming $this from incompatible context /usr/share/pear/PEAR.php line 871

Comments

 [2008-04-16 09:30 UTC] tacker (Markus Tacker)
Actually this is not a bug. If some process outside of Cache_Lite removes the cache files this will happen. Adding a file_exists() call will increase the runtime of the method and not report the fact that there is no cache file where one is expected. In a live environment you should suppress warnings and notices by using an appropriate error_reporting level.
 [2008-04-16 15:57 UTC] remicollet (Remi Collet)
Yes. I understand your perf argument. But i'm really sure there is no process outside of Cache_Lite which removes the cache files. Simple and stupid test : $cache->save("1234567890", "1"); $cache->remove("1"); $cache->remove("1"); Real Use case : You have an "database" object - when you read the DB : first call "get" and if not availalble, read the DB and call "save" - when you delete an object from the DB, you call "remove" to be sure no more cache there (even if you don't/can't know if one exists). Probably the file_exist can be only add to "remove" method. Another solution is to create a removeifexist method. Regards
 [2008-04-20 16:49 UTC] remicollet (Remi Collet)
New patch attached use another simple solution. A new option to remove method. Without (default valus is false), no check is done, so no perf. issue. Using this option set to true allow a developer to secure the call when he don't know about the cache status for the ID. Regards
 [2008-04-21 08:17 UTC] tacker (Markus Tacker)
That's ok for me. But you could also use this code: <?php error_reporting( E_ALL|E_STRICT ); ini_set( 'display_errors', 1 ); require_once 'Cache/Lite.php'; class MyCache extends Cache_Lite { /** * Remove a cache file * * @param string $id cache id * @param string $group name of the cache group * @param boolean $checkbeforeunlink check if file exists before removing it * @return boolean true if no problem * @access public */ function remove($id, $group = 'default', $checkbeforeunlink = false) { if (!file_exists($this->_file)) return false; parent::remove($id, $group); } } $MyCache = new MyCache; $MyCache->remove('foo');
 [2008-04-21 16:39 UTC] remicollet (Remi Collet)
Thanks for this taking care of this issue. Hum... Will also have to extend Cache_Lite_File, Cache_Lite_Function and Cache_Lite_Output... And we also need to call _setFileName to populate _file property (and probably check _memoryCaching and/or _onlyMemoryCaching) Think it's a quite complex solution. I always prefer the simplest way ;)
 [2008-05-31 16:37 UTC] remicollet (Remi Collet)
Hi Markus, Are you ok with the new option solution ? I'm waiting for news about this before i push this extension to Fedora/EPEL repository. And i also need it for GLPI (new version is near to be released). I'd like to use the "official" version, not a patched version Regards
 [2008-06-04 05:50 UTC] tacker (Markus Tacker)
> Are you ok with the new option solution ? Yes I'am. I will release an update this week.
 [2008-06-08 08:56 UTC] tacker (Markus Tacker)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net 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.