Updates fail if the file_metadata table already exists

I'm curious how this table existed before an install? Was it installed at one point but never uninstalled?

I have also run into this issue updating from 7.x-2.0-unstable7 to 7.x-2.0-beta1+25-dev.

When running drush updb -y, I have lots of updates, but it dies at file_entity_update_7211:

Do you wish to run all pending updates? (y/n): y
Table file_metadata already exists.                                                                                                                   [error]
Performed update: file_entity_update_7211                                                                                                             [ok]
Finished performing updates.

Oddly though, I tried this on a fresh install and couldn't reproduce. But I can confirm that before I updated, the file_metadata table was in the database, but the schema_version is at 7204. I've inherited the site, so I can speak for why this is the case. My suspicion is this scenario:
1. someone updated the code
2. ran the database updates
3. imported a db dump. which reset the schema_version, but didn't drop the newly added tables

This was documented previously in a similar ticket: #1901886: Update-Problems

Despite this probably being a user error, the patch does avoid the error preventing the updates. And it is a pretty harmless code change. RTBC++

Also, I found the location module had a simliar problem with a similar solution that committed: http://cgit.drupalcode.org/location/commit/?id=e61c0d5

Hmm Should we really write code like this? I have only seen stuff like this in scenarios like suggested in #6, or where admins mixed up media 7.x-1 and 7.x-2.x, jumped forth and back without rolling back from backup. I mean the error is a indication that stuff is wrong and they might have more in their installation broken. I think silently ignoring it might not be safe.

@steinmb, that is a really good point.
The site owners should responsible for their broken installs, not the module. Makes sense, the module can't account for all scenarios breaking the installation of the module.

If anything, is there a better way to exit the update script that doesn't prevent other update scripts from running, such as throwing the DrupalUpdateException?

The result is the same, an error message and the updates are halted. However, this probably follows better practice. Patch attached.

Is there a way to bypass an erroneous update in order to avoid preventing any other modules' updates?

I update drupal core to 7.43 version on my local enviroment.

Everything was good, but when I upload the code generated to update other server (I have a local copy from it), I got the same error: There are updates for the modules, I run the update.php and got the same error: file_metadata already exists (file_entity module).

Recently I just noticed that in production enviroment file_entity module looks with the version 7.x-2.0-beta2 and media module, looks with 7.x.1.5 version. On my local enviroment the situation is different, file_entity and media modules have the 7.x.1.5 versions, even when the code for file_entity is older (7.x-2.0-beta2).

I don't want to delete file_metadata table on production.

Thanks.

This appears to still be an issue.

I believe that previous versions of the file_metadata table are probably fine and don't need to be changed.

on mine in mysql, it has 3 columns as follows:

name  type
fid      int(11)           not null
name  varchar(255)   not null
value  longblob         null

  $schema['file_metadata'] = array(
    'description' => 'Cache images dimensions.',
    'fields' => array(
      'fid' => array(
        'description' => 'The {file_managed}.fid of the metadata.',
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ),
      'name' => array(
        'description' => "The name of the metadata (e.g. 'width').",
        'type' => 'varchar',
        'length' => '255',
        'not null' => TRUE,
      ),
      'value' => array(
        'description' => "The value of the metadata (e.g. '200px').",
        'type' => 'blob',
        'not null' => FALSE,
        'size' => 'big',
        'serialize' => TRUE,
      ),
    ),
    'primary key' => array('fid', 'name'),
    'foreign keys' => array(
      'file_managed' => array(
        'table' => 'file_managed',
        'columns' => array('fid' => 'fid'),
      ),
    ),
  );

I might suggest changing patch 9, instead of throwing an exception, maybe just drupal_set_message with a warning

Tried to reproduce this by installing an older pre 1.x file_entity (before it was a project it was a sub module of media 1.x) but could not reproduce the issue, when I upgraded from Media 1.6 to 2.0 I downloaded file_entity 2.0-beta3 and ran the updates and they all worked no issues.

I have same issue, What can i do?

Tried everything, and eventually the only thing that worked was to drop the table in question.