Edit report at https://bugs.php.net/bug.php?id=28790&edit=1
ID: 28790
Comment by: landeholm at gmail dot com
Reported by: jnoll at prim dot hu
Summary: Add php.ini option to disable stat cache
Status: Assigned
Type: Feature/Change Request
Package: *General Issues
Operating System: *
PHP Version: *
Assigned To: pollita
Block user comment: N
Private report: N
New Comment:
I'm writing a PHP CLI daemon and the stat cache just burned me hard because it
made file_exists() incorrectly return false for a file that had been created by
another program. There NEEDS to be a way to disable this. My only option now
appears to be to write my own file system wrapper functions to bypass this
annoying behavior.
Previous Comments:
------------------------------------------------------------------------
[2011-03-31 08:34:39] ras...@php.net
You guys realize that the stat cache is per-request, right? You only need to
clear the stat cache before a file_exists() call if you A. did a stat for it,
and
B. either created or deleted it on that request. In which case you shouldn't
need
to stat it again since the success status of the create/delete will tell you
whether the file is there or not. Perhaps for long-running daemons or something
this becomes more of an issue, but for a typical web request the stat cache
typically saves you dozens of system calls.
------------------------------------------------------------------------
[2011-03-31 06:47:29] giorgio dot liscio at email dot it
when this will be fixed?
when lot of users work on same files is needed to clear the cache on every call
to stat functions: this is totally annoying
in plus clearing the cache every time is slower against not cache at all
please fix :)
thank you
------------------------------------------------------------------------
[2007-05-23 22:57:09] bcurry at freeshell dot org
I'd like to second the motion for an .INI-option enabling the stat cache,
defaulting to 'true.' In my case, I would certainly set this option to 'false.'
In my humble opinion, the stat cache should either invalidate itself on every
file access and modification - or not cache entries, at all. I depend on
"file_exists" returning 'true' if a file exists, and 'false' if not. Enabling
the stat cache makes this (and similar) built-in functions behave
non-deterministically, and therefore un-reliably. The "speed" gain of caching
stat results is surely obviated by the fact that, to obtain reliable stat
results, one must call "clearstatcache" before every call to the "file_exists"
(and similar) built-in functions.
------------------------------------------------------------------------
[2006-12-31 09:17:43] james at bytehosting dot com
When writing a daemon process that accesses files very often it seems
litterally stupid to cache stat on these files.
With Basic Code such as the below, the statcache adds unneccessary overhead and
actully SLOWS down the code caching & purging the cache on EACH and EVERY
revolution of code.
There MUST be an option to disable it, other than rm -rf'ing the stuff from the
src/.
Regardless if you believe its "quicker" or not is moot, for each and every case
that you give where it is quicker, I can garuntee to give you a seperate case
proving where it slows the code down.
If your not willing to add a config option, how about a runtime option? (after
all, who needs ob_implicit_flush()? its just another 'useless' function...,
same idioligy applies here). And there are PLUNTY of cases where code such as
this is required (obviously, not the exact code, its pseudo code)
while (TRUE) {
clearstatcache();
if (file_exists("file.tmp")) {
process_stuff;
}
}
------------------------------------------------------------------------
[2004-06-16 17:30:45] poll...@php.net
I'll cut ya in on a secret: The statcache is only one entry long.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=28790
--
Edit this bug report at https://bugs.php.net/bug.php?id=28790&edit=1
