WordPress.org

Ready to get started?Download WordPress

Forums

WP Super Cache
Major BUG: Network Deactivating deletes files (8 posts)

  1. bigsite
    Member
    Posted 2 years ago #

    Never assume that it is safe to delete the files and directories in /wp-content/cache/. WP Super Cache recursively scans the /wp-content/cache/ directory and deletes anything it finds. This is NOT okay. WP Super Cache's behavior during network deactivation caused a disaster yesterday because there were custom symlinks in /wp-content/cache/ms-filemap/ and WP Super Cache stupidly decided to walk that subdirectory, wiping out every single file in there. Each symlink is mapped to /wp-content/blogs.dir/[blognum]/. Fortunately, we have pretty good backups, so the loss was minimal - just a few images. Without the backups, we would have lost pretty much everything thanks to this bug.

    Also, it looks like the deactivation process deletes the configuration. Please don't do that either - at least not without making a backup. Then, if someone activates the plugin again, look for a backed up config from a previous activation.

    Deactivation of all plugins should be near-instantaneous. Deleting the entire cache typically exceeds the length of time most servers allow scripts to run. If you want to allow someone to delete files on deactivation, let it be an option within the plugin itself that can be enabled (disabled by default).

    http://wordpress.org/extend/plugins/wp-super-cache/

  2. Donncha O Caoimh
    Member
    Plugin Author

    Posted 2 years ago #

    Why would you create a symlink in a "cache" directory to files like that? The cache directory is generally for temporary files.

    Unfortunately it's not really possible to second guess what people will do on their servers. You can't avoid symlinks because some people may actually have symlinks in there to temp folders holding temporary files.

    What I will do however is add a filter on the list of "protected directories" in the prune_super_cache() function in wp-cache-phase2.php.

    Best practices for deactivating plugins includes cleaning up after themselves which is what this plugin does. I am considering how to tackle this however as a number of people have complained about it.

  3. bigsite
    Member
    Posted 2 years ago #

    "Why would you create a symlink in a "cache" directory to files like that? The cache directory is generally for temporary files."

    Because WP multisite installs resolve file URLs by invoking WordPress, reverse-engineering the permalink, locating the file, and then serving it up. This file serving tactic doesn't happen with single blog installs, just multisite installs. The symlink approach allow for blog names to resolve cleanly to their internal numeric value and using a simple rewrite rule to point at the correct location. The symlinks themselves are the "cached/temporary" items, not the files/directories they link to. This approach makes perfect sense to me.

    If you feel you must delete files and directories on deactivation, please at least make a call to the PHP function is_link() and only remove the link so that you don't just blindly walk every directory deleting everything willy-nilly. The result will still be annoying but will be MUCH less painful.

  4. Donncha O Caoimh
    Member
    Plugin Author

    Posted 2 years ago #

    You could put those symlinks in the uploads directory. Sorry, I won't be putting an is_link() check in.

  5. bigsite
    Member
    Posted 2 years ago #

    Well-behaved programs on *NIX systems don't blindly traverse every directory while deleting files. Determining the difference between a symbolic link and a real directory is easy.

    WP Super Cache is already directly responsible for causing data loss.

    More importantly, I read your reply to mean that you aren't interested in preventing future data loss from happening.

    I see your stance on actual data loss as horribly wrong. If I learned that my software caused data loss, I would bend over backwards to make sure it never happened again.

  6. Gonçalo Peres
    Member
    Posted 2 years ago #

    Hi Bigsite and Donncha O Caoimh.

    This happened to me as well - I'm using "Nginx + WordPress 3 Network with multiple domains + WP Super Cache" and all the uploaded files on all blogs were deleted when i clicked the button "Delete Cache on All Blogs", which calls "prune_super_cache()" and delete everything inside "/wp-content/cache/".
    I used Bigsite approach to place symlinks inside this directory (/wp-content/cache/ms-filemap/).

    I now moved "ms-filemap/" dir to "wp-content/".
    Bigsite, it would be great if you could please edit http://codex.wordpress.org/Nginx, so others don't get their images deleted as well?

    While you are at it, you could substitute the PHP script that generates symbolic links by the one i suggested on http://wordpress.org/support/topic/nginx-php-fpm-php-apc-wordpress-multisite-subdirectory-wp-super-cache/page/2 (it's just a a slight improvement over yours)

    Donncha O Caoimh, it would be great if you could please change "prune_super_cache()", so it doesn't delete everything inside "cache/", just the WP-Super-Cache dir/files.

    Thank you both for sharing and helping the WordPress community.

  7. Donncha O Caoimh
    Member
    Plugin Author

    Posted 2 years ago #

    Gonçalo - I didn't know that codex page was there but I've edited it now and it recommends using wp-content/ms-filemap/ instead of the cache directory.

    I am really sorry that you suffered data loss. I'm going to add a note to the readme.txt warning users that only temporary files should be put in that directory.

  8. bigsite
    Member
    Posted 2 years ago #

    Multiple issues: A symlink on a modern filesystem isn't a file. The directory tree a symlink points to isn't meant to be walked during a tree delete. Calling the directory '/cache/' makes it look like it is a general place to store cached content for any plugin - NOTHING about the name says that it is ONLY for 'wp-super-cache' content. In my case, I recreate the symlinks every few minutes if they get deleted.

    WordPress, on our installation, also has a nasty habit of creating a (broken) symlink instead of a directory when setting up a new site, which I have to manually fix from the command-line. I strongly suspect this is due to our PHP opcode cache. It is conceivable that this plugin with a PHP opcode cache could create a working symlink that later causes severe data loss.

    Or let's suppose someone manages to somehow set up a symlink somewhere in the cache directory tree. If the admin later disables this plugin there will be severe data loss.

    The simple fix is to use 'is_link()' before traversing into what looks like a directory. The real fix is to stop deleting files on deactivation.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic