We recently upgraded from an old version of WP Super Cache (0.9 I believe) to 1.2, and we're now having problems with our RSS feed being stale. I did some digging, and it looks to me like the garbage collector isn't cleaning up the feed perhaps due to a bug. Here's the relevant debug log:
// hit feed for the first time w/ an empty cache dir
15:43:19 /blog/feed/ supercache dir: [...]wp-content/cache/supercache/www.example.com/blog/feed/
15:43:19 /blog/feed/ No wp-cache file exists. Must generate a new one.
15:43:20 /blog/feed/ In WP Cache Phase 2
15:43:20 /blog/feed/ Setting up WordPress actions
15:43:20 /blog/feed/ Created output buffer
15:43:23 /blog/feed/ Output buffer callback
15:43:23 /blog/feed/ Feed detected. Writing legacy cache files.
15:43:23 /blog/feed/ Supercache disabled: GET or feed detected or disabled by config.
15:43:23 /blog/feed/ Writing non-gzipped buffer to wp-cache cache file.
15:43:23 /blog/feed/ Renamed temp wp-cache file to [...]wp-content/cache/blogs/feed/wp-cache-feed0671fa3f67fb255e6141869e80660f1f.html
15:43:23 /blog/feed/ Sending buffer to browser
15:43:23 /blog/feed/ wp_cache_shutdown_callback: collecting meta data.
15:43:23 /blog/feed/ Writing meta file: [...]wp-content/cache/blogs/feed/meta/wp-cache-feed0671fa3f67fb255e6141869e80660f1f.meta// hit feed after it's been primed in the cache
15:44:09 /blog/feed/ wp-cache file exists: [...]wp-content\cache\blogs\feed\wp-cache-feed0671fa3f67fb255e6141869e80660f1f.html
15:44:09 /blog/feed/ Serving wp-cache static file
15:44:09 /blog/feed/ exit request// hit wp-cron when a GC is scheduled
16:01:46 /blog/wp-cron.php In WP Cache Phase 2
16:01:46 /blog/wp-cron.php Setting up WordPress actions
16:01:46 /blog/wp-cron.php URI rejected. Not Caching
16:01:46 /blog/wp-cron.php maybe_stop_gc: GC flag not found. GC will go ahead..
16:01:46 /blog/wp-cron.php wp_cache_gc_cron: Set GC Flag. ([...]wp-content/cache/www.example.com/blog_wp_cache_gc.txt)
16:01:46 /blog/wp-cron.php Cache garbage collection.
16:01:46 /blog/wp-cron.php Cleaning expired cache files in [...]wp-content/cache/
16:01:46 /blog/wp-cron.php Doing GC on supercache dir: [...]wp-content/cache/supercache
16:01:46 /blog/wp-cron.php gc: deleted [...]wp-content/cache/supercache/www.example.com/blog/feed, older than 600 seconds
16:01:46 /blog/wp-cron.php gc: could not delete [...]wp-content/cache/supercache/www.example.com as it's not empty: blog
16:01:46 /blog/wp-cron.php GC completed. GC flag deleted.
16:01:46 /blog/wp-cron.php scheduled wp_cache_gc for 10 seconds time.// hit the feed again just to show the cached file is still being served
16:22:55 /blog/feed/ wp-cache file exists: [...]wp-content\cache\blogs\feed\wp-cache-feed0671fa3f67fb255e6141869e80660f1f.html
16:22:55 /blog/feed/ Serving wp-cache static file
16:22:55 /blog/feed/ exit request
As you see, when the feed is requested, WP Super Cache generates the static cache file and then stores it in the wp-content\cache\blogs\feed\ dir. Later, when the GC uses wp_cache_phase2_clean_expired to clean up the expired files, the "while ... readdir" loop only looks at the files in that directory alone instead of recursing through all directories and files. The feed ultimately isn't GC'd then because it's in the blogs/feed/ folder instead of the top-level directory.
Can someone confirm that this is actually a bug and not somehow a misconfiguration?
