Just as an aside, Lynn and Peter are two more people who have had this issue - in addition to the folks mentioned in the various bugs about this. Really would like clear guidance on what's needed to move the PR on once I resolve the current merge conflict.
On Thu, Sep 2, 2021 at 9:49 AM Peter Bowyer <phpmailingli...@gmail.com> wrote: > On Thu, 2 Sept 2021 at 09:27, Kevin Lyda <ke...@ie.suberic.net> wrote: > > The change I've made will allow people to disable the > > cache so that it won't cause errors and it leaves the current broken > > behaviour in place. > > Is there any good reason not to remove it completely? Removing it completely would be ideal, however a number of people objected in the linked bug. And while it's not needed in modern Unix operating systems, it's not clear if Windows might benefit from this. Personally I'd argue that due to its buggy behaviour it should be removed. There's no way to make this work correctly in userspace so it's not a good place for it. OS and filesystem developers implemented caching on those levels because they have the state to properly maintain a cache. However if you use the filesystem a certain way and you pretend other processes can't modify a file out from under you, the current caching system could provide a performance benefit on OSs and filesystems that don't offer this sort of caching. And maybe someone depends on this. That's the best argument I can make for retaining it. > I've been bitten by the stat cache before and would be pleased to see it > gone for good. As have I. And I had to write some goofy sed scripts to insert clearstatcache() in order to stop rare bugs from popping up. Which means I had to experience it at least twice. Kevin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
