drush and multi-site and update/backup [#305489]

I have just started using this. It's very nice. One thing I've noticed, I'm using a multi-site setup and usually I have drupal core on a dedicated user account from the various sites. So when I try to run drush pm update just for one site I run into a situation where it's trying to create a backup in my drupal root folder (and it doesn't have write permission to that). I've traced it to this line (drush/drush_pm/drush_pm.module:279) --

$backup_dir = DRUSH_DRUPAL_ROOT. '/backup';

Would it be possible to make this configurable via drushrc or maybe even auto-detect?

Thanks - great system!

Comment	File	Size	Author
#3	drush_pm-5.patch	759 bytes	miiimooo
#3	drush_pm-6.patch	759 bytes	miiimooo

Comments

Comment #1

miiimooo

Europe

commented 8 September 2008 at 14:09

This would be a patch that does what I described above. I'm not sure whether it breaks drush in other situations:

Index: drush/drush_pm/drush_pm.module
===================================================================
--- drush/drush_pm/drush_pm.module      (revision 2)
+++ drush/drush_pm/drush_pm.module      (working copy)
@@ -276,7 +276,12 @@

     $skip_backup = module_invoke_all('drush_pm_skip_backup', $source);
     if (!count($skip_backup)) {
-      $backup_dir = DRUSH_DRUPAL_ROOT. '/backup';
+//      $backup_dir = DRUSH_DRUPAL_ROOT. '/backup';
+      $arrProjectPath = explode('/', $project['path']);
+      array_pop($arrProjectPath);
+      array_pop($arrProjectPath);
+      $arrProjectPath[] = "backup";
+      $backup_dir = DRUSH_DRUPAL_ROOT. '/'. implode('/', $arrProjectPath);
       drush_op('mkdir', $backup_dir, 0777);
       $backup_dir .= '/modules';
       drush_op('mkdir', $backup_dir, 0777);

Comment #2

clemens.tolboom

Dutch

Groningen, 🇳🇱/🇪🇺

commented 9 September 2008 at 07:23

Status:

Active

» Postponed (maintainer needs more info)

+1 for the above 'patch'.

The backup should reside in the parent directory of the project to be updated. Problem will be if one follows a directory scheme with subdirectories say 'sites/example.com/modules/views-modules/views/' then this 'patch' fails. (EDIT) This directory should be writeable in the first place ... the module is about to be replaced right? (end EDIT)

@miiimooo: please attach a patch and describe a test scenario (or a ref to a blog post :-)

Comment #3

miiimooo

Europe

commented 9 September 2008 at 10:29

Status	File	Size
new	drush_pm-6.patch	759 bytes
new	drush_pm-5.patch	759 bytes

Here you go :

fixes #305489: drush and multi-site and update/backup (and maybe #298048: drush update fails with "failed to backup project directory ... to ..."). I'm throwing in the drupal 5 patch. It's practically identical.

Comment #4

fen commented 24 December 2008 at 19:20

Any update on this? I tried the patch in comment #3 and still it seems to fail in the rename. I'm using --svnsync and am multisite. The first rename is the problem, but the second rename (that fails because of the first rename) has the correct paths. Here's an output listing:

> drush.php -v -l http://home.6 -r ~/workspace/drupal/6 --svnsync pm update
Update information last refreshed: December 24, 2008 - 10:36am

Update status information on all installed and enabled Drupal modules:
  Name                                  Installed version       Recommended version     Status                         
  ----                                  -----------------       -------------------     ------
  Administration menu                   6.x-1.1                 6.x-1.1                 Up to date
  CiviCRM Theme                         6.x-1.x-dev             6.x-1.2                 Update available
  Drush                                 6.x-1.2                 6.x-1.2                 Up to date
  CivicActions                          Unknown                 6.x-1.2                 Installed version not supported

Updates will be made to the following projects:
CivicActions [civicactions-6.x-1.2], CiviCRM Theme [civicrm_theme-6.x-1.2]

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 CivicActions ...
Backup skipped because .svn directory was detected. Use Subversion to revert if needed.
Calling chdir(/home/fen/workspace/drupal/6/sites/home.6/modules/contrib-stable/)
Updating project civicactions ...
update
0
Calling chdir(civicactions)
Executing: cvs update -dP  -r DRUPAL-6--1-2
  ? .svn
  ? tests/.svn
  cvs update: Updating .
  cvs update: Updating tests
Calling chdir(..)
Updating out civicactions was successful.
Project civicactions was updated successfully. Installed version is now 6.x-1.2.
Executing: svn status  civicactions
  M      civicactions/tests/CVS/Entries
  M      civicactions/CVS/Entries
You should consider committing the new code to your Subversion repository.
If this version becomes undesireable, use Subversion to roll back.
Starting to update CiviCRM Theme ...
Calling mkdir(/home/fen/workspace/drupal/6/backup, 511)
Calling mkdir(/home/fen/workspace/drupal/6/backup/modules, 511)
Calling mkdir(/home/fen/workspace/drupal/6/backup/modules/20081224140137, 511)
Calling rename(/home/fen/workspace/drupal/6/sites, /home/fen/workspace/drupal/6/backup/modules/20081224140137/civicrm_theme)
Calling chdir(/home/fen/workspace/drupal/6//)
Updating project civicrm_theme ...
update
0
Calling chdir(civicrm_theme)
Executing: cvs update -dP  -r DRUPAL-6--1-2
  ? .svn
  cvs update: Updating .
Calling chdir(..)
Updating out civicrm_theme was successful.
Project civicrm_theme was updated successfully. Installed version is now 6.x-1.2.
Executing: svn status  civicrm_theme
  A      civicrm_theme
  A      civicrm_theme/civicrm_theme.module
  A      civicrm_theme/civicrm_theme.info
  A      civicrm_theme/CVS
  A      civicrm_theme/CVS/Repository
  A      civicrm_theme/CVS/Root
  A      civicrm_theme/CVS/Entries
  A      civicrm_theme/CVS/Tag
You should consider committing the new code to your Subversion repository.
If this version becomes undesireable, use Subversion to roll back.
Starting to update Date ...
Calling mkdir(/home/fen/workspace/drupal/6/backup, 511)
Calling mkdir(/home/fen/workspace/drupal/6/backup/modules, 511)
Calling mkdir(/home/fen/workspace/drupal/6/backup/modules/20081224140137, 511)
Calling rename(/home/fen/workspace/drupal/6/sites/home.6/modules/contrib-stable/date, /home/fen/workspace/drupal/6/backup/modules/20081224140137/date)
drush: Failed to backup project directory /home/fen/workspace/drupal/6/sites/home.6/modules/contrib-stable/date to /home/fen/workspace/drupal/6/backup/modules/20081224140137/date

Comment #5

nschloe commented 15 June 2009 at 13:15

Hi,

any news on this one? I'm having the same issue here, except that -- to add some weirdness --, the global backup folder is actually writable for all users.
Hence, this

cp -r /usr/local/www/apache22/data/drupal/sites/win.ua.ac.be.~nschloe/modules/atom /usr/local/www/apache22/data/drupal/backup/modules/20090615150752/

is no problem at all, while drush still fails with

Calling rename(/usr/local/www/apache22/data/drupal/sites/win.ua.ac.be.~nschloe/modules/atom, /usr/local/www/apache22/data/drupal/backup/modules/20090615151421/atom)
drush: Failed to backup project directory /usr/local/www/apache22/data/drupal/sites/win.ua.ac.be.~nschloe/modules/atom to /usr/local/www/apache22/data/drupal/backup/modules/20090615151421/atom
Drush command could not be completed.                                [error]

Cheers,
Nico