|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #28790 Add php.ini option to disable stat cache
Submitted: 2004-06-15 15:43 UTC Modified: 2022-04-07 19:45 UTC
Avg. Score:4.8 ± 0.5
Reproduced:25 of 25 (100.0%)
Same Version:7 (28.0%)
Same OS:12 (48.0%)
From: jnoll at prim dot hu Assigned: ilutov (profile)
Status: Closed Package: *General Issues
PHP Version: * OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: jnoll at prim dot hu
New email:
PHP Version: OS:


 [2004-06-15 15:43 UTC] jnoll at prim dot hu
The problem is the following:

1. open a file for writing or appending
2. append a character (or anything) to that file
3. close file
4. get the file size with stat or filesize
ERROR: this will return the OLD size, before writing

If you do a clearstatcache(), the filesize will be the NEW size (the expected result)

Reproduce code:
 $filename = "/tmp/stattest";

 // initialise
 if (!file_exists($filename)) {
 	$f = fopen($filename,"w");
	echo "Reload, please.";

 $fs = filesize($filename); $fstat = stat($filename);
 echo "START: $fs, ".$fstat['size']."<BR>";

 $f = fopen($filename,"a");

  * bad result: this should be 1 byte more than the previous
 $fs = filesize($filename); $fstat = stat($filename);
 echo "AFTER(BAD): $fs, ".$fstat['size']."<BR>";

 // force a clear
  * good result after clearstatcache (why???)
 $fs = filesize($filename); $fstat = stat($filename);
 echo "AFTER(GOOD): $fs, ".$fstat['size']."<BR>";


Expected result:
START: 145, 145
AFTER(BAD): 145, 145
AFTER(GOOD): 146, 146

If AFTER(BAD) is less than AFTER(GOOD) value, that means PHP is buggy.


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-06-15 19:03 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

This is to be expected. 
 [2004-06-16 16:10 UTC] jnoll at prim dot hu
Okay, let me change this to a feature request!

After fclose(), the stat cache for that file should be cleared. Also, unlink and maybe copy should do this.
If a function is KNOWN to change file stat data, it should clear the cache.

The problem is that even a file_exists() call caches the data (including the file size!), and this is easy to overlook, when you have a bigger system.
 [2004-06-16 16:29 UTC]
Ilia was perhaps a bit short winded in his response...

This was actually discussed within the context of a feature change as well and was turned down on the basis that it would create unnecessary slowdowns without significant gain.

You should be aware when you're making multiple stat family calls to the same file and call clearstatcache() accordingly.  If you're uncertain, then just call it anyway.

However, that said it may be prudent to introduce an .ini option to disable the cache altogether now that stat calls work on arbitrary wrappers.  Let's leave this option open for PHP 5.1 for now.
 [2004-06-16 17:28 UTC] phpbugs at spam dot raszi dot hu
It would be better if the file modification functions invalidate not the whole statcache, only the entry of the modified file.
 [2004-06-16 17:30 UTC]
I'll cut ya in on a secret: The statcache is only one entry long.
 [2006-12-31 09:17 UTC] 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) {
  if (file_exists("file.tmp")) {
 [2007-05-23 22:57 UTC] 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.
 [2010-12-20 14:01 UTC]
-Summary: Add option to disable stat cache +Summary: Add php.ini option to disable stat cache -Package: Feature/Change Request +Package: *General Issues -Operating System: Debian GNU/Linux (unstable) +Operating System: * -PHP Version: 4.3.6 +PHP Version: *
 [2011-03-31 06:47 UTC] 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
 [2011-03-31 08:34 UTC]
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.
 [2012-01-17 20:23 UTC] landeholm at gmail dot com
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.
 [2012-01-17 20:38 UTC] landeholm at gmail dot com
Okay, the stat cache was not to blame for this problem I commented on above as I just learned it doesn't cache negative results but I still need a way to disable it. I could get problems in the future when file_exists returns true for a file that does not exist anymore.
 [2014-02-13 14:54 UTC] roman at litgroup dot ru
We really need this option to disable cache in daemons, written in PHP.
WebSocket server for example. Or some worker, which listens the queue and performs some jobs.
 [2017-03-08 21:42 UTC]
-Status: Assigned +Status: Open -Assigned To: pollita +Assigned To:
 [2017-03-08 21:53 UTC] spam2 at rhsoft dot net
> You guys realize that the stat cache is per-request

nonsense - it's per prcoess and "You only need to clear the stat cache before a file_exists() call" is bullshit, you should be able to clear it *after* change a file but you just paly lotterly for which request in the future clearstatcache() has any effect or was just a joke is a deisgn error wihich makes a) the cache mostly usesless and b) clearstatcache() to a lottery game
 [2017-03-09 11:23 UTC]
The stat cache is cleared between requests. What you have in mind is the realpath cache.
 [2020-07-25 09:37 UTC] kevin at lyda dot ie
Can this please be disabled. Modern operating systems have their own stat cache that is properly maintained. A cache on these systems reduces performance *and* causes subtle and frustrating errors.
 [2020-07-25 21:02 UTC] kevin at lyda dot ie
I've created a PR to do this. I don't know if the people who have participated in this bug to date get emails on updates to this bug, but if you do and have thoughts on the PR I'd be interested.
 [2020-12-18 13:39 UTC]
The following pull request has been associated:

Patch Name: Feature Request #28790 Add php.ini option to disable stat cache
On GitHub:
 [2020-12-18 13:45 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
well, can you also *stop now* disable the stat cache just because open_basedir is configured and let that decide the admin without forcing him to patch php-src
 [2021-09-04 19:53 UTC] kevin at lyda dot ie
Just a note to update bug 72666 if this gets resolved.
 [2022-04-07 19:45 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: ilutov
 [2022-04-07 19:45 UTC]
We're closing all feature requests on Since there already is a PR an open issue isn't necessary.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jun 24 00:01:30 2024 UTC