Update 7300 can delete core/contrib files

This is untested, any maybe there is a reason that $genclasses shouldn;t be empty and so something else actually needs fixing. But this patch should fix the error at hand and allow the update to run smoothly.

Or rather,

Yes, good point. That will probably explain my registry kept in an aegir migration. I did say it was untested! Ok, here is a better version that wont do that.

I tested this in Aegir and running drush update I no longer had any problems. Thanks for providing the patch upgrading to the latest mailsystem has now resolved another issue with it not finding my tpl files properly yahoo!

The patch in #5 works for me too.

#5 works for me, thanks.

La opción #5 de mrfelton me funciono.

The option #5 mrfelton is good.

Committed the attached patch to 3.x. Thanks, everyone!

Maybe this patch isn't necessary since ultimately the issue was improper drupal file system settings or server file permissions. However, if the bug does manifest, it is serious.

Since the accepted patch (#5) has already been applied to 7.x.3.x branch and this issue closed, my patch is meant to run after it (applied after the patch in #5 or applied to the current 7.x.3.x branch). Not sure how to best do that in the issue queue? Should I have started a new issue?

Background:
1) My troubed site used Drupal's private file system.
2) The site was running locally and the configured file system directory for the private files did not exist (or permissions were denying access).

The Outcome
When I ran this update a lot of my site's files in /includes/ /modules/ and /sites/*/modules/ were DELETED from the file system. Basically everything in my registry.

The Bug/Reason
drupal_realpath() will return false since the file directory was not accessible.
The $class_dir variable was getting cast as a string when concatenated with "/" ($classs_dir = "/").
The string manipulation (substr(), etc). strips this down to an empty string ($classs_dir = "").
The query condition ends up being a blank wild card ( filename LIKE "%" ). Hence all registry rows are found and subsequently removed from the registry and file system.

My Fix
A simple conditional to make sure drupal_realpath() does not return false, throw an error if its does.

Yikes. That's an edge case to be sure, but the consequences are bad enough that I think it's reasonable to put in the check that you're suggesting and throwing the exception. I'll keep this open for a while in case any other maintainers want to weigh in, but right now this is a thumbs-up from me.

To answer your issue queue question I think most maintainers prefer new issues once the status turns to Closed, but it's not a big deal either way - I'm glad you reported the problem at all! One thing you should do in the future is to change the Status to "Needs review" when you are providing a patch that you want a maintainer to look at.

Didn't know that, but that makes sense. Thanks, Joel!

When running update.php update 7300 still gives me the same error.

I'm using Mail System 7.x-3.0-alpha1

The error is the same:
Failed: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1: DELETE FROM {registry} WHERE (name IN ()) ; Array ( ) in mailsystem_update_7300() (regel 100 van C:\www\arlande.nl\sites\all\modules\contrib\mailsystem\mailsystem.install).

How do I proceed as this patch #11 is commited to Mail System 7.x-3.0-alpha1?

I ran into this today on a migration of site inside of the Aegir hosting platform when the update hook was run.

I've rerolled the patch in #14 against 7.x-3.x

You're commenting on a duplicate, the reason it didn't apply anymore is that the issue has been fixed in 7.x-3.x and is now already checked above this.