colinmollenhour / cm_cache_backend_file Goto Github PK

Hi Colin

We having been battling with the following errors that popup up at an alarming rate in our system.log file.

We have addressed prior issues relating to permissions and ownership file ownership and now all cache files are created with the correct permissions and ownership.

We are unclear why these errors appear and they seem to go hand in hand with performance issues in the admin interface. Incidentally these errors are limited to our dedicated admin server, the front end server with same code base does not suffer the same issue.

Given that we use a front end / backend duplicate instance set up should we make the change to use REDIS?

Any insights you can shed on this would be appreciated.

Thanks Laurie

Segment of cache directory - all files owned and with a group of Apache and with permissions 770:-

drwxrwx--- 2 apache apache 4096 Sep 9 15:59 cm--ed
drwxrwx--- 2 apache apache 4096 Sep 9 17:14 cm--ee
drwxrwx--- 2 apache apache 4096 Sep 9 17:04 cm--ef
drwxrwx--- 2 apache apache 4096 Sep 9 17:04 cm--f0
drwxrwx--- 2 apache apache 4096 Sep 9 17:04 cm--f1
drwxrwx--- 2 apache apache 4096 Sep 9 17:17 cm--f2
drwxrwx--- 2 apache apache 4096 Sep 9 14:51 cm--f3
drwxrwx--- 2 apache apache 4096 Sep 9 14:58 cm--f4
drwxrwx--- 2 apache apache 4096 Sep 9 17:05 cm--f5
drwxrwx--- 2 apache apache 4096 Sep 9 17:17 cm--f6
drwxrwx--- 2 apache apache 4096 Sep 9 15:02 cm--f7
drwxrwx--- 2 apache apache 4096 Sep 9 17:04 cm--f9
drwxrwx--- 2 apache apache 4096 Sep 9 14:48 cm--fa
drwxrwx--- 2 apache apache 4096 Sep 9 14:58 cm--fb
drwxrwx--- 2 apache apache 4096 Sep 9 15:08 cm--fc
drwxrwx--- 2 apache apache 4096 Sep 9 16:51 cm--fd
drwxrwx--- 2 apache apache 4096 Sep 9 15:05 cm--fe
drwxrwx--- 2 apache apache 4096 Sep 9 17:17 cm--ff
drwxrwx--- 2 apache apache 12288 Sep 9 17:17 cm-tags

Log entires:-
2014-09-09T10:06:41+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:07:53+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:31+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT_18686) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:38+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:38+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT_18686) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT_18684) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT_18684) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:47+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT_18685) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:47+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:47+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_CATALOG_PRODUCT_18685) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:54+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:54+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:54+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:08:54+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:09:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:09:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:09:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:09:43+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-09-09T10:10:13+00:00 DEBUG (7): file_get_contents(httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directoryhttpdocs/.modman/Cm_Cache_Backend_File/File.php

Sorry for open a ticker for mongodb cache backend here, but theres no issue tracker ;-)
https://github.com/colinmollenhour/Cm_Cache_Backend_Mongo

at the weekend i found out that the cache backend from magento/zend could not delete all old data. so there many data in the mongodb with a expired date.

so i created my own cronjob to handle this:
https://gist.github.com/mklooss/7626105
database size:
before: ~50 GB
after: ~5 GB

Mage::app()->getCache()->getBackend()->clean('old');

this script will not find all expired data :/

Hi!

Using:

• PHP 7.4.33
• Magento 2.4.3-p3 (Update, we moved this shop to Magento 2.4.5-p1 and PHP 8.1 and it still happened after yet another server crash)
• colinmollenhour/cache-backend-file 1.4.5

I noticed this error:

[2022-11-19 12:39:58] .CRITICAL: Notice: Trying to access array offset on value of type bool in vendor/colinmollenhour/cache-backend-file/File.php on line 149 [] []

This happened shortly after the hosting brought back a server to live, after it had crashed. So possibly some cached data could have been corrupted or something (this is just guessing).

Flushing the Magento cache stopped it from occurring.

This code probably needs more defensive code to prevent this warning and to do the right thing to make sure the cache is no longer corrupted?

Hi

This is a 1.7.0.2 install that uses ioncube and zenguard loaders. This is the error message I'm receiving.

Have not performed a code review as yet, but it is very slow to load the home page...

Any ideas?

Steve

In _getIdsByTags, with Zend_Cache::CLEANING_MODE_MATCHING_ANY_TAG, and multiple tags, the line
$ids = $ids + $this->_getTagIds($tag);
doesn't append correctly the ids to the $ids array.
Using
$ids = array_merge($ids,$this->_getTagIds($tag));
works.

Besides, __getTagIds adds an empty entry when an empty tag file exists, but doesn't contain any entry.

If used in the context of Backend/TwoLevels as a slow backend cache, this can lead to call remove on the fast backend, with "" as cacheId (and a potential full cache deletion).

Again, using
return array_filter($ids);
instead of
return $ids;

at the end of _getIdsByTags fixes this behavior.

Full fixed method :

/**
 * @param string $mode
 * @param array $tags
 * @return array
 */
protected function _getIdsByTags($mode, $tags)
{
    $ids = array();
    switch($mode) {
        case Zend_Cache::CLEANING_MODE_NOT_MATCHING_TAG:
            $ids = $this->getIds();
            if ($tags) {
                foreach ($tags as $tag) {
                    if ( ! $ids) {
                        break; // early termination optimization
                    }
                    $ids = array_diff($ids, $this->_getTagIds($tag));
                }
            }
            break;
        case Zend_Cache::CLEANING_MODE_MATCHING_TAG:
            if ($tags) {
                $tag = array_shift($tags);
                $ids = $this->_getTagIds($tag);
                foreach ($tags as $tag) {
                    if ( ! $ids) {
                        break; // early termination optimization
                    }
                    $ids = array_intersect($ids, $this->_getTagIds($tag));
                }
                $ids = array_unique($ids);
            }
            break;
        case Zend_Cache::CLEANING_MODE_MATCHING_ANY_TAG:
            foreach ($tags as $tag) {
                $ids = array_merge($ids,$this->_getTagIds($tag));
            }
            $ids = array_unique($ids);
            break;
    }
    return array_filter($ids);
}

You are using each() in File.php:81 which is deprecated in PHP 7.2 and throws a warning.
https://wiki.php.net/rfc/deprecations_php_7_2

Any chance you can update it?

Anyone help me how can i solve below error while running the command :

`C:\wamp\www\gta>php bin/magento setup:upgrade;

Fatal error: Uncaught Error: Class 'Cm_Cache_Backend_File' not found in C:\wamp
www\gta\vendor\magento\zendframework1\library\Zend\Cache.php:153
Stack trace:
#0 C:\wamp\www\gta\vendor\magento\zendframework1\library\Zend\Cache.php(94): Zen
d_Cache::_makeBackend('Cm_Cache_Backen...', Array, true, true)
#1 C:\wamp\www\gta\vendor\magento\framework\App\Cache\Frontend\Factory.php(155):
Zend_Cache::factory('Magento\Framewo...', 'Cm_Cache_Backen...', Array, Array,
true, true, true)
#2 C:\wamp\www\gta\vendor\magento\framework\App\Cache\Frontend\Pool.php(67): Mag
ento\Framework\App\Cache\Frontend\Factory->create(Array)
#3 C:\wamp\www\gta\vendor\magento\framework\App\Cache\Frontend\Pool.php(146): Ma
gento\Framework\App\Cache\Frontend\Pool->_initialize()
#4 C:\wamp\www\gta\vendor\magento\framework\App\Cache\Type\FrontendPool.php(84):
Magento\Framework\App\Cache\Frontend\Pool->get('default')
#5 C:\wamp\www\gta\vendor\magento\framework\App\Cache\Type\Config.php(49): Magen
to\Framework\App\Cache\Type\FrontendPool->get('config')
#6 C:\wamp\ in C:\wamp\www\gta\vendor\magento\zendframework1\library\Zend\Cache.
php on line 153

C:\wamp\www\gta>

`

I am facing issue by running cron in Magento 2

In ErrorHandler.php line 61:

Warning: file_put_contents(/data/html/var/cache//mage-tags/mage---935_CONFIG): failed to open stream: Permission denied in /data/html/vendor/colinmollenhour/cache-
backend-file/File.php on line 691

can you please help me.

Thanks in advance.

It seems like this module overwrites the core. I'm trying to avoid that so upgrading the core is simple, so it works with my build process, and the many other reasons altering the core is discouraged by the community.

In my attempt to refactor the module to extend, I see some things I didn't understand.

The module symlinks to app/code/community/Cm/Cache/Backend/File.php, but that file doesn't exist, although app/code/community/Cm exists.

Cm_Cache_Backend_File extends Zend_Cache_Backend_File, but Zend_Cache_Backend_File isn't currently a class in any Magento file.

The install instructions say change global/cache/backend to Cm_Cache_Backend_File, but I don't see "global/cache/backend" when I ctrl+f app/etc/local.xml. I don't even see "cache" when I ctrl+f.

Am I fundamentally misunderstanding how this module works? Have things changed in Magento 1.x that this module doesn't support? Any advice for my attempt to refactor this module?

I am currently on 1.9.2.4, and planning to upgrade soon to 1.9.3.3.

I am currently using windows and symlinks always return 0. I tried this to my linux server always zero when I Initialize Tag Symlinks. I am using your code changing Vinai's Symlink cache class that is integrated with this module http://www.magentocommerce.com/magento-connect/magento-cache-advanced-caching-with-advancedcache-by-soon.html.

Why this happens? can you create a module for this? =) I am using magento 1.9.1

When using this backend for both cache and Full Page Cache, the backend mixes files of them:

var/cache/mage--tags and var/full-page-cache/mage--tags as an example

Look like the files location is stored somewhere and used for both caches, which is incorrect.

Hi

I have a site that uses the original Netzarbeiter Symlink Filecache. I've changed to using eAccelerator recently and it's stopped working...so time to change maybe.

How to recommend upgrading to your extension? Best to remove the Netzarbeiter Symlink Filecache and install yours from scratch?

Any advice much appreciated.

Hello,
I've a configured Cm Cache backend File on a FPC, it works well.
I was wondering about how Cm File backend do housekeeping, does it remove files when the cache lifetime is over?
Currently I've got a huge amount of files 300k in my cache dir, juste want to know if I have to worry about fully filling my var/cache :)

We had an issue on a customer manager server (so we are not able to install redis or something else).

there are to many tag file in the tag directory and the hdd running out of inodes.

possible solution: Files Dispersion, like magento catalog product images
eg. media/catalog/product/i/m/image.jpg

We have the issue, that the cronjob core_clean_cache, which runs by default every night, never runs through and is always running until it is killed, as soon as the cache has a minimal size.
It can be "fixed" by running the cronjob every hour. Then the cache is so small, that it still works , but if you run it as default once a night, the issue occurs.
We already debugged this locally and found out, that the removal of specific cache entries takes more than a second, each.
So when the cronjob goes through the cache items, he should delete, some of them are easily removed within a very short time but some take that long, and we did not really find out, why.

We're using Magento with all Mage One patches applied and the newest version of this module.
The issue happens since we switched to PHP 8.1.

Does anyone encounter the same and has any ideas what we could try to fix it?

when i try to run command :
php .modman/Cm_Cache_Backend_File/FileBackendTest.php

i got error :

Warning: require_once(CommonExtendedBackendTest.php): failed to open stream: No such file or directory in /home/eden/public_html/.modman/Cm_Cache_Backend_File/FileBackendTest.php on line 4

please guide me if i am using wrong method.

Hi

On occasions we have found the Magento application to be failing, after investigation we found the following entries in the system.log:-

2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directory/var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directory/var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directory/var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directory/var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: No such file or directory/var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_CATALOG_NOTIFYSTOCK) [function.file-get-contents]: failed to open stream: No such file or directory/var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php
2014-06-30T08:47:16+00:00 DEBUG (7): file_get_contents(/var/www/vhosts/domain/httpdocs/var/cache//cm-tags/cm---dbc_BLOCK_HTML_RSS_ORDER_NEW) [function.file-get-contents]: failed to open stream: /var/www/vhosts/domain/httpdocs/.modman/Cm_Cache_Backend_File/File.php

Our cache directory looked like this at the time of error:-

drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--c6
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--c9
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--cd
drwxr-xr-x 2 root root 4096 Jun 30 10:55 cm--cf
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--d0
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--d6
drwxr-xr-x 2 root root 4096 Jun 30 10:49 cm--dc
drwxr-xr-x 2 root root 4096 Jun 30 10:55 cm--dd
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--de
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--e0
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--e4
drwxrwx--- 2 apache apache 4096 Jun 30 10:48 cm--e7

Whilst we have umask(0007) set in index.php we did the following to ensure the cache remains readable to all of the Magento applications incarnations...

In the first instance we made sure cron.php and any instance of the app were run by apache, using the apache cron tab etc, that eliminated the root entires and then we called umask(0007) in Mage.php to ensure all have the correct umask, as Mage.php is always called for all incarnations of the Magento application.

As of now all entries in our cache directory are owned by apache and have the same permissions and we are waiting for another instance of the race type condition that caused some parts of the application to become unresponsive. Hopefully this has fixed this problem!

I am posting this for any other insights users and developers may have regarding similar issues.

Thanks Laurie

Hi,

I get an error performing action "Flush cache storage" :

Warning: Invalid argument supplied for foreach() in /xxxxx/app/code/community/Cm/Cache/Backend/File.php on line 478 :

foreach (glob($this->_tagFile('*')) as $tagFile) { // Causes error

Issue on 1.7.0.2

Any idea ?

Since Update 1.4.6 there is a change of caching behavior which has effects to Magento Framework.

Steps to reproduce:
Use Cm_Cache_Backend_File::save with no $specificLifetime (= false).
Zend_Cache_Backend::getLifetime (Cm_Cache_Backend_File ~197) returns null, but Update converts null to an int.
Zend_Cache_Backend_File::_expireTime returns $time() + 0, so lifetime is already expired.

In Version 1.4.5 the int Conversion is not there, so $lifetime is still null and Zend_Cache_Backend_File::_expireTime returns 9999999999 which means unlimited lifetime.

There is no update von Zend_Cache_Backend with changend functionality so default functionality with this update to 1.4.6 were changed.

Hi,

Using the backend with a pure ZF 1.11 application, and Two level cache, I noticed that cache--tags files were disappearing.

I traced it to __clean, which when called with Zend_Cache::CLEANING_MODE_OLD destroys cache_tags directory in the process.

Here is my modified version :

protected function _clean($dir, $mode = Zend_Cache::CLEANING_MODE_ALL, $tags = array())
{
    if (!is_dir($dir)) {
        return false;
    }
    $tagsDir = $dir . $this->_options['file_name_prefix'] . '--tags';
    $result = true;
    $glob = @glob($dir . $this->_options['file_name_prefix'] . '--*');
    if ($glob === false) {
        return true;
    }
    foreach ($glob as $file)  {
        if (is_file($file)) {
            switch ($mode) {
                case Zend_Cache::CLEANING_MODE_ALL:
                    $result = @unlink($file) && $result;
                    continue;
            }

            $id = $this->_fileNameToId(basename($file));
            $_file = $this->_file($id);
            if ($file != $_file) {
                @unlink($file);
                continue;
            }
            $metadatas = $this->_getCache($file, false);
            if ( ! $metadatas) {
                @unlink($file);
                continue;
            }
            switch ($mode) {
                case Zend_Cache::CLEANING_MODE_OLD:
                    if (time() > $metadatas['expire']) {
                        $result = $this->_remove($file) && $result;
                        $result = $this->_updateIdsTags(array($id), explode(',', $metadatas['tags']), 'diff') && $result;
                    }
                    continue;
                default:
                    Zend_Cache::throwException('Invalid mode for clean() method');
                    break;
            }
        }
        if ((is_dir($file)) and ($this->_options['hashed_directory_level']>0)) {
            // Recursive call
            if (!($mode == 'old' && $file == $tagsDir)) {
                $result = $this->_clean($file . DIRECTORY_SEPARATOR, $mode) && $result;
                if ($mode == 'all') {
                    // if mode=='all', we try to drop the structure too
                    @rmdir($file);
                }
            }
        }
    }
    if ($mode == 'all') {
        foreach (glob($this->_tagFile('*')) as $tagFile) {
            @unlink($tagFile);
        }
    }
    return $result;
}

ZF 1.12 renamed "hashed_directory_umask" and "cache_file_umask" to "hashed_directory_perm" and "cache_file_perm", respectively.

Because of the manner in which Zend_Cache_Backend_File handles options, this causes files to be created with 0000 permission.

Related: http://framework.zend.com/issues/browse/ZF-12047

Hey Colin,

I am using your optimized file cache, it work great .... i think cause benchmark are good ; )
My conf is the following : two level cache - apc & Cm_Cache_Backend_File

When i use this conf :

my cache is generated in directories named this way :

var/cache/cm--**

when i use a two-level configuration :

directories looks like this :

var/cache/mage--0

it looks like the way magento usually handle cache generation.
So am not pretty sure your cache backend is actually used ....

What's your thinking ?
and BTW a big thanks to you for all your work on cache and redis !
and on this one a big thanks to Vinai ;)

Hi,

I have a small problem with my custom script for creating XML files (with products). I am using external file with loading magento over Mage::app('storeview','store'); and loading products collection.

If I switch on Cm_Cache in local.xml file, memory usage during script run grow up with each load of product from collection. If Cm_Cache is disabled, memory usage is +- same during loading products.

Is there any method to disable Cm_Cache only for custom script?

Thank you for your help and your great work on Cm_Cache,
Lukas

Edit:
Problem is not Cm_Cache file, I tested script on virtual server with Cm_Cache and run fine. So, I must search... :-)

Due to implementation of _clean method directory traversing it will traverse tags folder as well as regular cache folders.

When it will go down to tags folder it will wipe out all tag files from that folder, while keeping actual cache records related to those tags.

This will render tagged cache clearing unusable for those records that survived after clean('old') was called.