drush update google_analytics deletes the sites directory !

This certainly looks like the same issue, but that one should be fixed in 2.0. Hence, either the fix is incomplete, or this is really a different issue.

Would you be able to help debug this on your system, or perhaps figure out a way to reproduce it reliably (e.g. by dl an old version of a module, enabling and then updating?).

I had a very similar problem, and I traced it back to having a symlink in my modules directory. It tried to update a module that was symlinked, decided it didn't like it and deleted /sites. Odd behaviour, but it's definitely an issue.

So, @pban02 :

have you searched recursively your drupal install for symlinks? I would use: "find . -type l" to search for all symlinks beneath the current dir...

Next - have you examined pathauto's dir for anything strange?

Lastly do you have any modules/core patched? Try using my script for that if in doubt ( google for "drupdatecode" to find it )

I just had this happen to me. I made the mistake of not putting this under version control, but lucky I was located at servint, who backs up sites.

I think that the symlink theory is right on.

After running drush update views (updating that module) I hit a pathauto error.

require_once(): Failed opening required 'sites/all/modules/pathauto/pathauto.inc' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/public_html/sites/all/modules/pathauto/pathauto.module on line 84

Then my /sites/* was gone!

What was weird is I ended up typing cd views I think (to far back now) and it took me to:
/home/public_html/backup/

I was in /sites/all/modules when I was running drush commands. I forgot to mention I'm running the latest HEAD version of drush.

Just had a similar thing happen to me, was fortunately able to recover from a backup. I got the same require_once() error except I forget in what and can't get to it through the buffer now. Pathauto is not installed on this site. The only module being updated was Captcha. I notice that one of the similar, older issues listed mentions that it is affected by having custom or custom-named modules and we do have a custom module installed on the site; it worked fine doing roughly the same update on a site with no custom modules.

Really, we need a concrete way to reproduce this problem, or a patch. Please help, folks.

I have the same issue with "drush update". After update of module logging_alerts the whole 'sites' folder is gone (the 'all' and 'default' folders of the 'sites' folder are moved to the backup/modules/yyyymmddhhmmss/logging_alerts. The 'sites' folder itself is really gone.

Here it happens:
Project logging_alerts was updated successfully. Installed version is now 6.x-1.4.
Module emfield directory could not be found at [error]
/var/www/vhosts/standing-strong.com/subdomains/test/httpdocs/sites/default/modules/emfield,
perhaps the module is enabled but has been deleted from disk.

At the moment the module 'emfield' is about to be updated, it's already gone.

Thats a good clue, elanghout . Hopefully someone can isolate the bug and contribute a patch based on it.

Actually this behavior (sites directory moved to backup) is the exact same behavior that was reported in http://drupal.org/node/445498

At the time I managed to reproduce this and tracked it down (or so I thought) to update module sometimes returning an empty $release['path'] for a project. The following code fixed it for me at the time:

    if (empty($release['path'])) {
      drush_set_error('DRUSH_PM_UPDATING_NO_PROJECT_PATH', dt('Module !project path is not available, perhaps the module is enabled but has been deleted from disk.', array('!project' => $release['name'])));
      continue;
    }
    if (!is_dir($source)) {
      drush_set_error('DRUSH_PM_UPDATING_PATH_NOT_FOUND', dt('Module !project directory could not be found at !source, perhaps the module is enabled but has been deleted from disk.', array('!project' => $release['name'], '!source' => $source)));
      continue;
    }

We need some help here from people who can reproduce this.

Bump - maybe the OP or some other folks on this chain can try to reproduce again; maybe #433950: Modernize updatecode command improved the situation?

I actually reproduced this once during my work on #433950: Modernize updatecode command and added a check that the project directory is within modules (or themes or whatever), which worked for me when simulating the issue - see below. It doesn't fix the underlying issue, because (of course) when I ran a second time it worked fine, so I couldn't figure out the cause - my guess is some kind of caching or race issue to do with multiple copies of a module in the same site.

    // Check that the directory exists, and is where we expect it to be.
    if (stripos($release['path'], $release['project_type']) === FALSE || !is_dir($release['full_project_path'])) {
      return drush_set_error('DRUSH_PM_UPDATING_PATH_NOT_FOUND', dt('The !project directory could not be found within the !types directory at !full_project_path, perhaps the project is enabled but has been deleted from disk.', array('!project' => $release['name'], '!type' => $release['project_type'], '!full_project_path' => $release['full_project_path'])));
    }

Am tentatively closing - if anyone notices this reoccurring on HEAD please reopen.

Hey, updates that simply fail are way better than updates that remove the sites directory. That's a big improvement.

Meh, I kinda liked removing the sites directory once in a while - it kept folks who ignored the (big all caps) warnings and tried to update their live site on their toes ;)

Funny. Maybe drush updatecode should delete the sites folder if there were more than N users logged on to the site when it was brought offline (or always if the site was still online for the updatecode). Of course, we'd have to add a big all caps warning telling the admin that their sites folder was going to be deleted instead of updated. ;)

Happened to me:

Update status information on all installed and enabled Drupal modules:
Name Installed Proposed Status
version version
Administration menu 6.x-1.5 6.x-1.5 Up to date
Drupal 6.16 6.16 Up to date
Backup and Migrate 6.x-2.2 6.x-2.2 Up to date
Comment Notify 6.x-1.4 6.x-1.4 Up to date
Content 6.x-2.6 6.x-2.6 Up to date
Construction Kit
(CCK)
FileField 6.x-3.2 6.x-3.3 SECURITY UPDATE available
GMap Module 6.x-1.x-dev 6.x-1.0 Update available
Google Analytics 6.x-2.2 6.x-2.2 Up to date
ImageAPI 6.x-1.6 6.x-1.8 Update available
ImageCache 6.x-2.0-beta10 6.x-2.0-beta10 Up to date
ImageField 6.x-3.2 6.x-3.3 SECURITY UPDATE available
Insert 6.x-1.0-beta2 6.x-1.0-beta4 Update available
jQuery UI 6.x-1.3 6.x-1.3 Up to date
Link 6.x-2.8 6.x-2.8 Up to date
Location 6.x-3.x-dev 6.x-3.0 Update available
Mollom 6.x-1.12 6.x-1.13 Update available
Nodequeue 6.x-2.5 6.x-2.9 Update available
Pathauto 6.x-1.2 6.x-1.3 Update available
Poormanscron 6.x-1.1 6.x-1.1 Up to date
Simplenews 6.x-1.1 6.x-1.1 Up to date
Thickbox 6.x-1.5 6.x-1.6 Update available
Token 6.x-1.12 6.x-1.12 Up to date
Troll 6.x-1.x-dev 6.x-1.x-dev Up to date
Views 6.x-2.10 6.x-2.10 Up to date
Views PHP Filter 6.x-1.0-beta1 6.x-1.0-beta1 Up to date
Wysiwyg 6.x-2.0 6.x-2.1 Update available
Acquia Marina 6.x-1.9 6.x-3.0-beta1 Installed version not
supported

Code updates will be made to the following projects:
FileField [filefield-6.x-3.3], GMap Module [gmap-6.x-1.0], ImageAPI [imageapi-6.x-1.8], ImageField [imagefield-6.x-3.3], Insert [insert-6.x-1.0-beta4], Location [location-6.x-3.0], Mollom [mollom-6.x-1.13], Nodequeue [nodequeue-6.x-2.9], Pathauto [pathauto-6.x-1.3], Thickbox [thickbox-6.x-1.6], Wysiwyg [wysiwyg-6.x-2.1], Acquia Marina [acquia_marina-6.x-3.0-beta1]

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 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 filefield was updated successfully. Installed version is now 6.x-3.3.
Project gmap was updated successfully. Installed version is now 6.x-1.0.
Project imageapi was updated successfully. Installed version is now 6.x-1.8.
Project imagefield was updated successfully. Installed version is now 6.x-3.3.
Project insert was updated successfully. Installed version is now 6.x-1.0-beta4.
Project location was updated successfully. Installed version is now 6.x-3.0.
Project mollom was updated successfully. Installed version is now 6.x-1.13.
Project nodequeue was updated successfully. Installed version is now 6.x-2.9.
Project pathauto was updated successfully. Installed version is now 6.x-1.3.
Project thickbox was updated successfully. Installed version is now 6.x-1.6.
Project wysiwyg was updated successfully. Installed version is now 6.x-2.1.
Module acquia_marina path is not available, perhaps the module is [error]
enabled but has been deleted from disk.
Backups were saved into the directory [ok]
/home/mgmcewen/huntgatherlove.com/backup/modules/20100516111751.

Fatal error: require_once(): Failed opening required './sites/all/modules/backup_migrate/includes/crud.inc' (include_path='.:/usr/local/php5/lib/php:/usr/local/lib/php') in /home/mgmcewen/huntgatherlove.com/sites/all/modules/backup_migrate/backup_migrate.module on line 208
Drush command could not be completed.

What version of Drush are you using?

2.1, should this be a new issue then?

drush-2.1 is unsupported. You'll have to either fix it yourself, or move to drush-3.0-stable. I recommend the later.