eaccelerator.filter not working correctly

forgot to give details (duh):

eAccelerator 0.9.5-rc1 [shm:mmap_anon sem:spinlock]

PHP 5.1.6 [ZE 2.1.0] Using apache2handler on FreeBSD servername 6.1-RELEASE-p3 FreeBSD 6.1-RELEASE-p3 #2: Wed Sep 13 14:56:33 BST 2006 root@servername:/usr/src/sys/amd64/compile/SERVER amd64

This server has 2 dual core opterons in it.

I saw that some bugs in the filter were resolved in r209, but since I am using 0.95-RC1, which appears to have been tagged at r243, I should already have those yes?

Yeah, you should have those. But the filter performs really bad.

In eaccelerator.c, eaccelerator_compile_file(),

eaccelerator_ok_to_cache(realname TSRMLS_CC);

changed to

eaccelerator_ok_to_cache(file_handle->filename TSRMLS_CC);

And broke it. Looks simple enough to fix.

Never mind I guess it's more like around line 1408 it needs ok_to_cache there.

Oh, and for me using file_handle->opened_path works better than file_handle->filename

Sorry about the spam :)

I kicked out the old filter implementation and I'm using fnmatch, for now this breaks windows support. Before 0.9.6 this should be fixed (I should start looking for someone whom windows machine I can hijackt to fix this). The plan is to use a bsd-licensed implementation when the platform doesn't have a fnmatch implementation.

Btw, this is in rev [299]

No reaction by the reporter so I'm going to close this one and assume it's fixed.

I'm using eAccelerator 0.9.5.1 on a SUSE Linux 10, with Apache 2.0.54, PHP 5.0.4.

This is does not appear to be fixed. AFAICT, only the first pattern in eaccelerator.filter is taken into account.

As noted by a previous poster, some things don't work as they are described in the documentation. Briefly, this seems to be the case:

"/path/one* /path/two*" only first path seems to be taken into account "!/path*" doesn't seem to work at all "!*.php" works

I didn't say it was fixed in 0.9.5.1, it's fixed in the development version. These fixes will be in 0.9.6 NOT 0.9.5.1!

Sorry - I misunderstood.

I'm not sure if this would be included in the latest snapshot, so I tried 0.9.6-svn327-dev, but I get similar results.

eaccelerator.filter = "!/usr/share/php5/PEAR/symfony*"

I see these cached files:

1. /usr/share/php5/PEAR/symfony/vendor/creole/Creole.php

2. /usr/share/php5/PEAR/symfony/vendor/creole/SQLException.php

3. /usr/share/php5/PEAR/symfony/vendor/creole/Connection.php

4. /usr/share/php5/PEAR/symfony/vendor/creole/ResultsSet.php

eaccelerator.filter = "!/usr/share/php5/PEAR/symfony* !/usr/share/php5/PEAR/symfony/vendor/creole*"

Has the same results.

I also tried checking out the trunk, but make falls over. Please note that I do realise that I can't expect the trunk to be stable.

I'm seeing the same thing here with FC4. I was using a filter

eaccelerator.filter = "!/var/www/vhosts/thepoultrykeeper.co.uk/subdomains/forums/httpdocs/cache/sql !*.inc *.php"

And .inc's and the SQL cache directory is being cached.

I've just had to fix this for my company's website, and thought I'd just provide the patch here for you guys who use linux and want it working on a non-development version. The attached patch may work on other versions of unix, probably not on windows however. YMMV, Use at your own risk, etc.

The above attached patch makes 0.9.5.2 behave as specified in the documentation under (at least) Centos 5.1.

By this, I mean that it uses the absolute canonical file path to make a match against, '*' will cross direcory boundaries (so /home* would match anything in home or any subdirectory thereof, and *.php matches any php file in any folder), slashes are not escaped.

One extra thing included in this patch is all patterns are case-insensitive, if this is not desirable for you, remove the FNM_CASEFOLD option from the 2 fnmatch() calls.

Enjoy!

Just a note for people attempting to use norganna's patch on Mac OS X who may be getting a segfault in httpd when using eA with mod_php...

I had to change this:

 char *rpath

to:

 char rpath[MAXPATHLEN];

and this:

 rpath = realpath(file_handle->filename, NULL);

to:

 realpath(file_handle->filename, rpath);

I guess technically this:

 rpath = realpath(file_handle->filename, NULL); 
 if (!rpath) {

should be:

 if (!realpath(file_handle->filename, rpath)) {

...but since rpath contains filename when realpath() returns NULL on OS X (as opposed to undefined as on some systems) then the change in the previous comment works though the change in this comment is a better general solution as the pointer returned in either case is NULL when the filename can't be resolved.