snedley

I had that happen to me as well. Two things to check:

1) Make sure you create a download directory, preferably outside the wordpress directory tree. It should be owned and writable by the web server process. Then select this directory in the plugin’s settings box.

2) Check the table names. My site’s prefix was different from wp_ but some of the rsfiles tables got created with the wp_ prefix. I renamed the tables and everything started to work.

Well some good news. At least deactivating the plugin restored my comments. Thankfully the plugin doesn’t delete the comments from your DB when you enable this thing.

I must say, even though some here say it’s compatible with 2.8, not having it listed as such in the wordpress directory isn’t a comforting feeling.

I just installed this plugin, did a comment import, and it freaking blew away all my site’s comments. I see some of them are flagged as deleted inside the disqus panel, along with a lot of spam. I’m certainly not going through them all and re-approve only the valid ones and not the spam.

Very very disappointed and upset.

Hopefully I can uninstill this hunk of crap and restore from DB to get my user’s comments back.

One other item on above …. when it’s running, the parent shell is…

weave      31357 31352  1 22:28 ?        00:00:00 sshd: weave@notty

Is the @notty indicative of no shell output going back up the pipe?

In the source it tests if the files exist.

if ( !$wp_filesystem->exists($from . '/wordpress/wp-settings.php') || !$wp_filesystem->exists($from . '/wordpress/wp-admin/admin.php') ||
                !$wp_filesystem->exists($from . '/wordpress/wp-includes/functions.php') ) {
                $wp_filesystem->delete($from, true);
                return new WP_Error('insane_distro', __('The update could not be unpacked') );
        }

The exists function runs that “ls -lad” command which I assume tries to check the output of the command, and if there is no STDOUT output getting back to the script, then maybe it just thinks the files are not there, and fails?

Here’s another “me too” post for the core update.

I’m also using SSH to do updates, and the plugin updates works fine.

I *thought* it might be the timeout value, but I went into the source and changed it from 300 to 900 but it failed after about 5 minutes still.

The files were unpacked into the ./core/wordpress/ directory fine, then they start disappearing one by one as I saw processes like the following being run…

bash -c ls -lad /var/www/wordpress/wp-content/upgrade/core/wordpress/wp-includes/js/tinymce/themes/advanced/source_editor.htm; echo “__COMMAND_FINISHED__”;

Then when all the files were deleted, the failure message happened.