[wp-hackers] Bizarre /cache/ experience with wp_object_cache.lock

[Ryan Boren]

Mark Jaquith wrote:
> I just had a rather strange experience with the object cache.  I just  
> moved my site to a new server, and I deleted the contents of the /wp- 
> content/cache/ directory before moving.  At the new host, I was  getting 
> 80+ queries on my front page (redundant option hits).  I  chown/chmod'd 
> my /cache/ directory into oblivion... I was confident  that I had it set 
> correctly... but nothing.  Then, out of  desperation, I started moving 
> files from another WP install's cache  into my cache.  Once I moved 
> wp_object_cache.lock into my /cache/  directory, it started working.
> 
> I took out all the error suppressing @s from /wp-includes/cache.php  in 
> an effort to try to get it to throw an fopen() error, but it  didn't 
> make a peep.  If /cache/ wasn't there, it wouldn't be created,  even 
> though the permissions were set up so that it could.
> 
> Why can't WordPress create this file?  Why wasn't WordPress reverting  
> to the old caching method (i.e. select all options where autoload =  '1' 
> and store them in memory for that load)?


We were seeing this with safe_mode enabled, which is why the cache is 
now disabled if safe_mode is on.  What happens in the safe_mode case is 
that WP thinks it can write because is_writable() returns true.  The 
cache isn't really writable, however, and later attempts to write to the 
cache fail.  We don't revert to the old method because is_writable() is 
telling us that we are able to write to the cache even though that isn't 
the case.

Ryan