Re: Adding a way to disable the stat cache
| From: | Nikita Popov | Date: | Fri, 03 Sep 2021 15:23:52 +0000 |
| Subject: | Re: Adding a way to disable the stat cache | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115934@lists.php.net to get a copy of this message | ||
On Fri, Sep 3, 2021 at 4:08 PM Kevin Lyda <kevin@lyda.ie> wrote:
> On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
> <cschneid@cschneid.com> wrote:
> > If I remember correctly it was about reducing the number of system
> calls. Is this no issue any more?
> > Has a quick benchmark been done to see the positive / negative impact of
> the stat cache for a typical application?
>
> In the lifespan of php it really wasn't an issue unless someone was
> doing something that wasn't wise - I can't think of a single reason to
> stat a file in a tight loop.
>
> However more importantly the current behaviour returns bad data for
> perfectly correct programs. So for example on a unix box...
>
> <?php
> passthru('touch foo');
> if (is_file('foo')) {
> echo "Correct\n";
> }
> passthru('rm foo');
> if (is_file('foo')) {
> echo "Incorrect\n";
> }
> ?>
>
> Now this is a silly toy, but imagine using is_file to see if a
> graphics file exists, running an image processing program on it to
> modify it, and then using a stat call to get the file length to
> populate the Content-Length field - it will almost certainly be wrong.
>
Just to throw it out there: Maybe we should clear the stat cache when
functions in the exec family are used? Even if we allow disabling the stat
cache, I think we can easily avoid that particular footgun. And if calls to
external binaries are involved we likely don't have to worry about stat
overhead.
Regards,
Nikita