Drush 3.0-alpha1 fails when upting a D6 site with various errors.
Code updates will be made to the following projects:
NodeReferrer [nodereferrer-6.x-1.0-rc1], Pathauto [pathauto-6.x-2.x-dev], Feeds [feeds-6.x-1.0-alpha11]
(...)
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
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
Project nodereferrer was updated successfully. Installed version is now 6.x-1.0-rc1.
Backups were saved into the directory /var/www/drupal/backup/modules/20100212174544/nodereferrer. [ok]
Looking good so far.
Project pathauto was updated successfully. Installed version is now 6.x-2.x-dev.
Backups were saved into the directory /var/www/drupal/backup/modules/20100212174544/pathauto. [ok]
Seems still OK...
The feeds directory could not be found within the disabled-modules directory at /var/www/drupal/sites/all/modules/feeds, perhaps the [error]
project is enabled but has been deleted from disk.
What is an "disabled-modules directory"? /var/www/drupal/sites/all/modules/ is my enabled modules directory...
The 'feeds' module exists at /var/www/drupal/sites/all/modules/feeds, but the module is disabled.
An error occurred at function : drush_pm_updatecode [error]
WD php: rename(/var/www/drupal/backup/modules/20100212174544/pathauto,/var/www/drupal/sites/all/modules/pathauto): Directory not empty in [error]
/root/drush/includes/drush.inc on line 305.
What is Drush trying here? Restore an backup over an successfull (as stated above) update?
Could not restore backup and rollback from failed upgrade. You will need to resolve manually. [error]
What is supposed to have failed? updating pathauso succeeded...
WD php: rename(/var/www/drupal/backup/modules/20100212174544/nodereferrer,/var/www/drupal/sites/all/modules/nodereferrer): Directory not [error]
empty in /root/drush/includes/drush.inc on line 305.
Could not restore backup and rollback from failed upgrade. You will need to resolve manually. [error]
An error occurred at function : drush_pm_update
The same bogus again, Drush seems to try to restore an backup over an successfull update and is failing while doing so.
The backup directory was being created, but it doesn't include the 'feeds' module:
# ls /var/www/drush/backup/modules/20100212174544/
nodereferrer pathauto
Repeating this procedure, Drush still fails:
Code updates will be made to the following projects:
Feeds [feeds-6.x-1.0-alpha11]
(...)
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
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
The feeds directory could not be found within the disabled-modules directory at /var/www/drupal/sites/all/modules/feeds, perhaps the [error]
project is enabled but has been deleted from disk.
An error occurred at function : drush_pm_updatecode [error]
An error occurred at function : drush_pm_update
All this sounds a bit as if Drush would feel like running amok a bit. I don't quite understand what it is trying and why it is failing. On the same server, Drush works without these issues on other D6 installations (separate codebase).
Thanks & greetings, -asb
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | drush-712788.patch | 0 bytes | jonhattan |
| #14 | drush-712788.patch | 1.74 KB | jonhattan |
| #12 | drush-712788.patch | 1018 bytes | jonhattan |
| #9 | drush-712788.patch | 1.99 KB | jonhattan |
Comments
Comment #1
moshe weitzman commentedComment #2
jonhattanit seems a problem related to the fact that feeds is disabled. It is theorically imposible because drush 3.x should show:
the
disabled-modulesthing comes because of the interaction of update_advanced when drush is unable to find the project on disk and hits:It seems to me the project was disabled in a second terminal when pm-update was fetching data from updates.drupal.org and before the call to update_advanced_update_projects_alter(), that sets the project type to disabled-modules if it is disabled. Or perhaps older versions of drupal 6.x checked also for disabled modules.
Comment #3
jonhattanI haven't used update_advanced before. Now I've seen it adds this option to update settings: Check for updates of disabled modules and themes. With that checked the problem is reproducible.
Comment #4
asb commentedComment #5
asb commentedYes, I have 'update_advanced' installed & enabled usually.
Comment #6
oskar_calvo commentedGreat job jonhatthan, thanks ;)
I love drush :)
Oskar
Comment #7
marthinal commentedYes jonhattan thanks for your time and your help !!
Comment #8
greg.1.anderson commentedI think this just needs some documentation somewhere to instruct users to not use "Check for updates of disabled modules and themes" when using update_advanced.
Comment #9
jonhattanWow it seems I have a fanclub :p
We already check for disabled projects requested but it is neutralized by update_advanced. With attached patch (untested) this situation is improved, but I think it will still fail if a disabled project has a update available, although it was not explicitly requested.
I also think pm-updatecode is almost ready to be compatible with update_advanced. It is only needed to have the path to the extensions in $project['includes'] (or similar).
Comment #10
mlncn commentedNow that this feature of update_advanced is in Drupal 7 core's Update Manager module (admin/reports/updates/settings), this is a major bug.
My error message is slightly garbled but it's definitely the same situation:
"The ctools project path is not available, perhaps the module-disabled[error]
is enabled but has been deleted from disk."
Drupal is checking the status of disabled modules, and drush attempts but is unable to update disabled modules and so the entire
drush upcfails (or actually, succeeds up to that point, but tells you it fails, and further tells you its rollbacks fail).The patch from #9 breaks drush for me.
In any case i think the approach should be to have drush upc update disabled modules, or do not list them as needing updates at all.
Comment #11
moshe weitzman commentedI can confirm that D7 with that checkbox (admin/reports/updates/settings) is broken. Here is a replay script.
check the box at admin/reports/updates/settings
drush dl ctools-7.x-1.0-alpha1 -y
drush en ctools -y
drush dis ctools -y
drush upc ctools
Note that pm-updatecode fails with the message above.
Comment #12
jonhattanI still think we are pretty near of being able to update disabled projects.
This patch is conservative and just get rid of disabled projects to continue with pm-updatecode as usual.
Comment #13
moshe weitzman commentedIIRC, drupal's update.php does update disabled modules so we should ideally match its behavior.
Comment #14
jonhattanpatch to update disabled projects. It works if the box is checked (d6 and d7).
Comment #15
moshe weitzman commentedWorked for the ctools test. Committed.
Comment #16
mlncn commentedFollow-up issue #1033380: Non-variable passed by reference warning caused by _pm_get_update_info() for disabled modules
Comment #17
dhbanes commentedJust tested in D6 with latest HEAD and still receive the following error when running "drush upc" with update_advanced enabled and "Check for updates of disabled modules and themes" checked:
The views_bulk_operations project path is not available, perhaps the -module is enabled but has been deleted [error] from disk.Comment #18
jonhattanIt is a bug introduced yesterday when fixing #1033380: Non-variable passed by reference warning caused by _pm_get_update_info() for disabled modules. Now fixed in head.
Comment #20
daniorama commentedI use D7 with "Check for updates of disabled modules and themes" enabled. Using both drush 5 and 4 dev versions I still experience the error:"The xxx project path is not available, perhaps the -module is enabled but has been deleted [error] from disk." Does it happen to anyone else?
Comment #21
jonhattanwoops I have failed badly several times to correctly implement basic arithmetics. Now fixed in HEAD.
Comment #22
jonhattanto be backported.
Comment #23
msonnabaum commentedMaybe that patch is supposed to have something in it? :)
Comment #24
jonhattanSorry. Here's the diff: http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands...
Comment #25
daniorama commentedTested on version 5 and now it updates disabled modules perfectly. Thanks! :) there is still the problem of just updating a random number of modules and not all of them once. It needed passing 6 times "drush up" to make sure all modules were updated.
Comment #26
msonnabaum commentedBackported.
http://drupal.org/commitlog/commit/2320/2cb68cdaa5cd35b93bb825d3b89c8ea9...