There are two cases where this causes a bug
Create a brand new page immediately after setting $UseCache back to 1. This has the side effect of completely flushing the cache (at least with the current code).
Remove the $UseCache tests from appropriate code so that the cache is always flushed after an edit, even with $UseCache=0. This is a poor fix as it will try to delete a cached page for every page in the system every time an edit occurs, with a probable performance hit.
As for the poor bug fix, but rewrite code to flush cache so that it only tries to delete files that actually exist. This will not take much time where no files exist, and will also enhance the performance in the cached case as a welcome side-effect.
If I have time I will post a fix as a Patch, but if it is not here by the end of Jan 2002 assume I didn't have time!
Actually, my assumption was that people would completely remove the cache and all of its files whenever they changed the $UseCache setting. (If they are enabling the cache, they should get rid of old files. If they are disabling the cache, they can get rid of the unused cache files.) The cache setting is not really meant for ordinary use as it has some known problems. The cache option remains in the code because it may be useful as a temporary measure under sudden high-load conditions (like a MeatBall:SlashDotting). If one expects continuous high loads, one should use a PersistentCGI solution like the Apache mod_perl module. --CliffordAdams