Re: realpath() caching

> >I wouldn't introduce a new function but just have clearstatcache() do > >this. And I don't think we should use ini_set("realpath_cache_size", > >0) for this as one then has to do ini_set() twice just to flush but still > >use the cache. > > > >The caches (stat and realpath) introduce enough magic to PHP so I'd at > >least keep the solution (clearstatcache) as simple as possible. > > What I meant was that any re-setting of this INI parameter (even if the > cache size is the same) would flush the cache. I think this is fine because > in real life, I don't think anyone will need it anyway. It's VERY rare to > change symlinks in a way which will affect this. > Right, and people *do* make changes to files which necessitate the need to invalidate the stat cache. Given that difference and the fact that they're really just plain two different things: I don't want to see clearstatcache() tied to the realpath() caching in any way. On a side topic, I've been meaning to expand the statecache beyond a single item, something along the lines of what Andi's done with realpath() caching. I'd also like to introduce an additional configuration option (please don't cringe too much) to reflect the fact that stat() family calls now support protocol wrappers (many of which are network based). I think it'd make sense to allow clearstatcache() to selectively clear all cache entries, or only entries for wrappers which do not have the is_url bit set. I briefly considered making the stat cache global (to share the speed up with all), but that has the potential to introduce a BC break (a script which relies on a stale cache?), and opens the door to some possible safe_mode circumventions (User A stats a file he's allowed to, then User B hits the cache). We could throw in some additional safe mode checks at that point, but then we're just adding complexity in to cover up the stat calls taken out. Kind of a zero-sum (or even negative sum) balance there.... Thoughts? -Sara