Hello,

I have tried using drush multiple times. It would really make my server administration better. Unfortunately it keeps on messing up. I have tried either linking it to the /usr/local/bin folder or making a .profile for "drush" in my Drupal root.

Every time I run "drush pm update" it gives me the message "failed to back up module ..." and deletes some modules. It should be updating them but it deletes them.

Any suggestions?

Thanks a lot!
-ROR

Comments

clemens.tolboom’s picture

You did not give much info. Try the verbose switch.

Which user is running drush? And where and what user is drupal installed?

root_of_roots’s picture

Hey thanks,

I am not sure exactly what you mean by "which user"? Drupal has been installed via the root user, therefore it is edited by "sudo" commands. Although recently we globally changed server permissions for another user.

Drush is installed for root, so I run it via "sudo". Drush is installed in /var/www/website//sites/all/modules/drush.

Thanks,
-ROR

clemens.tolboom’s picture

My guess is you run drush like

sudo php /var/www/example.com/sites/example.com/modules/drush/drush.php --root=/var/www/example.com/sites/example.com --uri=example.com -v pm update

Try 'drush -v' or 'drush --verbose' maybe that helps a little

root_of_roots’s picture

Nope. As I said, I made the links and the profile.

So I could run it from /var/www/ as "drush" or alternatively (with the .profile) from the Drupal root as "drush". For both I would sometimes try "sudo drush"...
I even ran it manually "sudo php ...".

It triggered drush successfully each time. Just "pm update" gave the error "Failed to backup module..." and then when I checked the ../modules folder some modules were deleted. Unpacking the modules back into the directory, however restored everything to how it was previously.

Cheers,
-ROR

clemens.tolboom’s picture

You are not giving much info. Please run drush --verbose then show the output here :-)

root_of_roots’s picture

Will do!

Thanks for investigating...

grendzy’s picture

root_of_roots’s picture

The OP didn't mention disappearing modules in the previous thread.

btw - I have not forgotten about this, I just had a rough week at school.

Regards,
-ROR

kruser’s picture

For me Drush is deleting the entire modules directory upon trying to update! By process of elimination it only deletes the modules directory when updating the filefield module.

Updates will be made to the following projects:
FileField [filefield-6.x-3.0-alpha6]

Note: Updated modules can potentially break your site. It's not recommended to update production sites without prior testing.
Note: A backup of your package will be stored to backups directory if no .svn directory is found.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue? (y/n): y
Starting to update FileField ...
Calling mkdir(/var/www/carrington_drupal/backup, 511)
Calling mkdir(/var/www/carrington_drupal/backup/modules, 511)
Calling mkdir(/var/www/carrington_drupal/backup/modules/20090129144623, 511)
Calling rename(/var/www/carrington_drupal/modules, /var/www/carrington_drupal/backup/modules/20090129144623/filefield)
Calling chdir(/var/www/carrington_drupal//)
Updating project filefield ...

Executing: cvs -z6  -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d filefield -r DRUPAL-6--3-0-ALPHA6 contributions/modules/filefield
  cvs checkout: Updating filefield
  cvs checkout: Updating filefield/filefield_meta
  cvs checkout: Updating filefield/filefield_meta/translations
  cvs checkout: Updating filefield/filefield_token
  cvs checkout: Updating filefield/filefield_token/translations
  cvs checkout: Updating filefield/ico
  cvs checkout: Updating filefield/icons
  cvs checkout: Updating filefield/icons/protocons
  cvs checkout: Updating filefield/icons/protocons/16x16
  cvs checkout: Updating filefield/icons/protocons/16x16/mimetypes
  cvs checkout: Updating filefield/po
  cvs checkout: Updating filefield/translations
Updating out filefield was successful.
Project filefield was updated successfully. Installed version is now 6.x-3.0-alpha6.
Backups were saved into the directory /var/www/carrington_drupal/backup/modules/20090129144623.
You should now run update.php through your browser.
kruser’s picture

Version: 6.x-1.1 » 6.x-1.2
Category: support » bug
Priority: Normal » Critical

I tried this again on separate site and it wiped out my entire /sites directory! It happened after it upgraded imagecache:

Project imagecache was updated successfully. Installed version is now 6.x-2.0-beta6.
drush: Failed to backup project directory /

This should probably be upgraded to critical since it's wiping out entire directories of modules without warning.

moshe weitzman’s picture

Status: Active » Closed (duplicate)

all this code changed.

root_of_roots’s picture

What is it a duplicate of? Is it fixed now?

grendzy’s picture

Status: Closed (duplicate) » Closed (won't fix)

I'm guessing wontfix is what was intended, meaning it won't be fixed in the old version.

If you see this problem in the new HEAD version, probably opening a new issues is best.