drush: Failed to backup project directory using php4

FWIW, Same error when using the drush pm update alone.

are you using the verbose flag? should give more info.

Hi Moshe,

Here's an example of what I'm seeing...

FWIW, I i'm using Update Status 5.x-2.1

Thanks for your help.
Mike

As you can see, it is the rename that is failing, probably because of a permissions issue. You need to fix that, or suggest a solution that works easily and more reliably.

Same problem at my install. running 5.8 dev and drush RC3

I've tried to change permissions of both modules and the backup directory in any way I could think of, but I still got the same error. I suspect the mkdir function failed as I can not seem to find the directories it was supposed to create.

I tried cheating by commenting out the backup calls in drush_pm.module. But then I got this error:

It appears stripos is a new php5 function (http://no2.php.net/manual/en/function.stripos.php)
I tried replacing the stripos call with an old strpos call using strtolower on the cvsmethod variable, and everything seemed to work ok.

I could not figure out the backup problem though.

-Olegu

Same for us. Drupal 5.7 with Drush 1.0

Right now unfortunately Drush is unusable.

In our case at least, it was related to PHP 4.

We are running PHP 4.4.2. The mkdir command used by drush to create the backup directory was failing since PHP 4 doesn't seem to support the recursive parameter.

Solution:
- manually create the backup/modules directory
- in drush_pm/drush_pm.module, change the line:
$ret = drush_op('mkdir', $backup_dir, 0777, TRUE);
to
$ret = drush_op('mkdir', $backup_dir, 0777);

Awesome, this worked for me, thanks.

i'd take a patch so this works in php4 and 5.

The attached patch gets rid of the recursive parameter to mkdir and, instead, calls mkdir 3 times. Tested on PHP4 and PHP5 and it seems to work the same in both places.

I snuck in a 3 character fix for http://drupal.org/node/219595 which takes the timestamp in the backup directory name to the second.

Looking at the original poster's drush output, I would say that that particular problem is with rename(), not mkdir(). I had the same problem and narrowed it down to rename(), which apparently can't move files between partitions. I had my site directory symlinked in from another partition, and this broke pm update as my modules directory and backup/ was on different partitions.

The patch may still be needed for PHP 4, I'm using PHP 5.

It looks like rename() fails, but indeed it is mkdir() that fails silently in the generic PHP4 case where different partitions are not involved.

@anyone having problems on PHP4 - please test the patch and let us know if it fixes your problem.

Patch didn't work:

[root@login public_html]# drush pm update themesettingsapi
Update information last refreshed: Sun, 04/06/2008 - 08:53

Update status information on all installed and enabled Drupal modules:
Name Installed version Recommended version Status
---- ----------------- ------------------- ------
Theme Settings API 5.x-2.0 5.x-2.7 Update available

Updates are available for the following projects:
Theme Settings API [themesettingsapi]

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
PHP Fatal error: Call to undefined function: stripos() in /home/domains/mydomain.com/public_html/sites/all/modules/drush/drush_pm_cvs/drush_pm_cvs.module on line 81

Fatal error: Call to undefined function: stripos() in /home/domains/mydomain.com/public_html/sites/all/modules/drush/drush_pm_cvs/drush_pm_cvs.module on line 81

This is not the patch.
I mention this a bit further up (http://drupal.org/node/218740#comment-726049).

Stripos is a php5 function that can be replaced by

-Vidar

@Vidar - does the patch work for you when you add in the stripos fix?

Up until now I have not had the time to test it.

But tonight, when I finally had some time, I found that the patch utility was not installed on my ISPs testserver, and I just couldn't get the Gnu32 patch utility to work on my new Vista machine.

So now I'm going to bed, all empty inside.

I could really need some advice on getting some sort of diff / patch utilities up and running on my Vista machine.

-Vidar

After running the patch and the Stripos replacement I got it to work. But I think it either caused a bug , or there is one in the core of drush. Whatever module I update directly through drush (i.e. drush pm update webforms) leaves a blank version number for the module on the admin modules page. If I update the module manually this works fine.

I've tested the patch together with the stripos fix, and everything runs without any errors.
But after I've updated with drush, and drush tells me everything has gone successfully, this is not reflected in the "available updates" screen. The screen still shows old version numbers after the drush powered update. I do not know if this is related to drush, or to the update status / cvs deploy modules. When I check the tags using CVS status, I have the correct tags for the updated files, so it seems like the modules are updated. Rerunning drush pm update does not reflect the changes either, but as far as I've understood how pm update works it just fetches the same list as provided by update status / cvs deploy.

-Vidar

Committed. Thanks everyone.

Automatically closed -- issue fixed for two weeks with no activity.