filemtime

[golowenow]

Have been searching ZC Support forums for this and there is absolutely nothing referencing this PHP warning. I have been getting this warning in my server log for fastcgi lately with the latest ZC version 1.3.7.1.

PHP Warning: filemtime() [<a href='function.filemtime'>function.filemtime</a>]: stat failed for F:/Program Files/Abyss Web Server/htdocs/store/cache/zc_56bef17b17fbeb6627441de26659411d.sql in F:\Program Files\Abyss Web Server\htdocs\store\includes\classes\cache.php on line 58
PHP Warning: filemtime() [<a href='function.filemtime'>function.filemtime</a>]: stat failed for F:/Program Files/Abyss Web Server/htdocs/store/cache/zc_56bef17b17fbeb6627441de26659411d.sql in F:\Program Files\Abyss Web Server\htdocs\store\includes\classes\cache.php on line 58

It appears to occur on session files that no longer exist(the .sql file changes) as their time limit is up and they are cleaned out of the CACHE folder. Is this a possible bug in ZC or should this warning be ignored? In a short period of time it does clutter up the fastcgi.log and I prefer it to be at 0 KB...hehe. Perhaps a code change is needed in the includes/classes/cache.php?

My system and settings are
PHP version 5.2.2 Strict mode
My SQL database version 5.0.45
Zencart version 1.3.7.1
OS is Windows XP SP2
Session configurations are:

define('STORE_SESSIONS', '');
define('SQL_CACHE_METHOD', 'file');
define('DIR_FS_SQL_CACHE', 'F:/Program Files/Abyss Web Server/htdocs/store/cache');

The cache folder IS writable. Any info on this is greatly appreciated.
Thank you

[DrByte]

Is there a reason for using "file" method for caching instead of "database" ?

[golowenow]

Yes Dr. Byte,
In the past I have had the sessions table crash in the database thus causing problems. When I switched to the "file" system these problems went away. In reading the ZC forums have also read that the "file" system is faster for clients then the "database" system in page load times. My site is flash and java oriented and thus I try to use every option possible for the pages to open for clients as fast as possible. Also I run the server from my own main PC using Comcast so...hehe... it is a little slower just for that reason. A question is that the session files saved in the cache folder are cleaned up after a specific amount of time. I am not an expert in code. Is there a place in ZC to increase the save time or is it in the PHP.ini file? Thank you for looking at this.
Best regards.
JLowe

[DrByte]

I haven't looked at that part of the code in a long time. But I can attest that I've not seen errors anything like that when using Apache as the webserver and using 'file' as the cache method.

[golowenow]

Could just be because of some upgrading I have done. Upgraded to the new PHP 5.2.4. There was a bug where when you try to login to admin an infinite loop occured. Found out at Aprelium to set Abyss webservers PHP scripting to STANDARD instead of PHP STYLE solved the problem. Session files are deleted after 24 minutes for security reasons. Still I wonder if something in the ZC code is not registering with PHP 5.2+ to stop the filemtime function from trying to occur when the session file no longer exists. PHP DOES still have problems with the FASTCGI process so it could be on their end as Aprelium has stated they are still messing around with the basics of PHP PATH_INFO/PHP_SELF. I googled the filemtime function and there is not a lot of info out there on it other than it timestamps the file when being reopened. Most links go to websites that are having the issue occur and somehow their logfile is being read by google. Probably not in their ROBOTS.TXT file for their particular server hehe.
Anyway I will keep an eye on my fastcgi log and see what happens over the next few days. Deleted all info in it so now on a clean slate. Wish it would show dates and times of the error so I could compare it with the access log and see what is being called in the cart. Uhoh...may have to talk to Aprelium again about THAT issue. Hmmm...new suggestion?
Thanks for looking Dr. Byte.
Best to you.
JLowe