It seems that images added to a node via an image field become permanently un-deleteable, even if they are removed from that node, and even if that node is then deleted. This seems to occur any time an image is attached to a node, regardless of the initial upload method. That is, if an image is uploaded via the media listing page, then attached to a node, it will subsequently be stuck in the system even if removed from the node.

CommentFileSizeAuthor
#10 1240834_10_media_forced_delete.patch1.6 KBszantog
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aspilicious’s picture

aspilicious CreditAttribution: aspilicious commented

I had the same problem with undeletabled files and images. Frustrating

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

Seems this might also be a problem with user pictures. On my test site, the first user picture wasn't uploaded correct, thus not shown either on the user page or as thumbnail in the media browser. After uploading a working picture, I tried to use the media browser to delete the old one (really just a file name viewed), but media browser said it couldn't because the file was in use.

idflood’s picture

idflood CreditAttribution: idflood commented

I've tried to reproduce the error without luck. This was on a fresh drupal 7 + media-2.x + dependencies installed with git. Here are the steps I tried

  1. create an article, upload a picture with the default image field and save.
  2. try to delete it via admin/content/media: not possible (as expected). edit the article, remove the image from the node edit form. Then the image was not listed anymore in the admin/content/media page
  3. upload an image directly from admin/content/media page for further use
  4. add a media field to the page content type. create a page, attach the previously uploaded image and also upload a new one.
  5. again, try to delete the images via admin/content/media: not possible (as expected)
  6. edit the page, remove the media attached and try again. the images are not even listed ( as expected )

Did I miss something?

aspilicious’s picture

aspilicious CreditAttribution: aspilicious commented

Maybe this is caused by an upgrade from an older version of media.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I suppose it's possible this is caused by an upgrade issue. I did upgrade from the 1.x branch. However, I've tested by completely uninstalling all media related modules and reinstalling, which is about as close as I can get to a fresh install. No dice.

I thought it might be possible this is caused by some sort of other module conflict. I tried uninstalling Entity Cache to see if there was some weird caching thing going on, but that doesn't seem to be involved.

Digging into MySQL I've discovered that my trouble files are present in the file_usage table and listed as being in use by the nodes in question. This means they are not being properly removed from the file_usage table, and not simply being mis-identified as being in use after the fact. In fact, if the image is then re-added to the node, the usage count is upped by one. I have numerous usage counts at 5+ per node, which generally seems impossible unless the client has been adding the same image to the body copy multiple times.

I have the feeling (though I'm not positive) the problem can be traced to line 381 of media.fields.inc where the usage count is supposed to be reduced by one. Clearly, this doesn't seem to be happening, though I'm unsure exactly which check is failing.

  // Compare the original field values with the ones that are being saved.
  $original_fids = array();
  if (!empty($original->{$field['field_name']}[$langcode])) {
    foreach ($original->{$field['field_name']}[$langcode] as $original_item) {
      $original_fids[] = $original_item['fid'];
      if (isset($original_item['fid']) && !in_array($original_item['fid'], $current_fids)) {
        // Decrement the file usage count by 1.
        $file = (object)$original_item;
        file_usage_delete($file, 'media', $entity_type, $id, 1);
      }
    }
  }
Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Priority: Normal » Major

After much investigation I have figured out this is caused by the revision system in core. Every time a new revision is created for an entity, the usage count in the file_usage table tying that entity and any file which happens to be on it at the time increases by one. If you delete the file, save the entity, and make a new revision, the usage count will not decrease because that count and file are still tied to older revisions of the entity. This happens in both the file_field_update and media_field_update functions.

  // On new revisions, all files are considered to be a new usage and no
  // deletion of previous file usages are necessary.
  if (!empty($entity->revision)) {
    foreach ($items as $item) {
      $file = (object) $item;
      file_usage_add($file, 'file', $entity_type, $id);
    }
    return;
  }

The only way to remove files which are tied to an entity with revisions is to delete all older revisions for that entity, or to manually go in and reduce the usage count in the database. Deleting the entity entirely doesn't actually seem to clear the usage count.

So this is not actually a Media issue, it's a core issue. Or at least, it's an issue when the default revision handling is combined with the Media module. Hard drive space concerns aside, I suppose it makes sense to keep an image around if there are older versions of a entity using it. Using the default file field setup, you really have no idea what's happening with your files under the hood and it doesn't really affect the user much if there's hundreds of files stacking up.

However, when using Media, all those leftover files are just going to keep piling up in the Media browser and you'll never be able to do anything with them unless you go back and delete all the entity revisions which are keeping them in the system. This seems to be far less than ideal.

A solution might be to check every field_revision_field_NAME table in the database and compare file IDs to see if which items have been deleted from the current revision of the entity they are attached to. These items could then be hidden from the Media browser. If you reverted to a previous revision of an entity they would be shown again.

A potential downside of this method might be the large number of lookups required (I assume) and the fact that each field seems to have a separate revision table in the database. Another potential downside might be user confusion over why files they thought they removed mysteriously reappear at a later time (A better problem to have than un-deleteable files though).

For the moment, my solution is probably going to be to turn off revisions and remove all older revisions so my users can clear out their Media library. They'll lose the ability to revert back to older content but at least they'll be able to mange their assets how they're expecting.

mlncn’s picture

mlncn CreditAttribution: mlncn commented

Just did much of this investigation myself. here's the keyword text i couldn't find before: "The file X is in use and cannot be deleted."

The if (!empty($entity->revision)) { check is always true, in my tests, and then the return statement means the file_usage_delete() function is never called. This is because revisions are enabled for the relevant content type.

Moving this code down 'fixes' the use case when a file is removed from a node before there are any revisions. But that's by pretending the file is no longer associated with the revision that just got saved. Drag.

So long as files are used by revisions, it makes sense that they need to exist. If the admin list could be filtered by 'active' images that would be great but seems that would be hard to do.

Will look into Views for alternate admin UI that doesn't have to show all images.

wmostrey’s picture

wmostrey CreditAttribution: wmostrey commented

I'm running into the same issue, and it's also happening in 7.x-1.0-beta5. The solution we come up with for this problem should be back-ported.

Related issue: #892352: Confusing things happen when you click "Delete" or "Cancel" on the Media delete form starting from comment #6.

fictionindustries’s picture

fictionindustries CreditAttribution: fictionindustries commented

Still broken with 7.8 release :(.
subscribing

szantog’s picture

szantog CreditAttribution: szantog commented
Title: Cannot delete images added via an image field on a node » Cannot delete images added via an image field on an entity, what is previously deleted
Status: Active » Needs review
FileSize
1240834_10_media_forced_delete.patch1.6 KB

I think, I could solve this.
Yesterday worked on that: #1274524: More useful warning message, if media isn't deletable. I created an error message for this case too.
Today I've figured, why just print the nid, what doesn't exist, why don't work with it?

Sorry, I mixed a little bit this with my previous issue, but I think, this is nearby connection with that.

I think, if the the content doesn't exist, we should force to delete the media.

szantog’s picture

szantog CreditAttribution: szantog commented
Status: Needs review » Needs work

This isn't perfect, it only works, when content is deleted.. Unfortunatly, there is a core issue: #1191438: file_usage not updated after removing a file/image field

wmostrey’s picture

wmostrey CreditAttribution: wmostrey commented

Shouldn't we just make this a duplicate of #1191438: file_usage not updated after removing a file/image field then?

nlambert’s picture

nlambert CreditAttribution: nlambert commented

subscribe

CarbonPig’s picture

CarbonPig CreditAttribution: CarbonPig commented

subscribe - same issue

amateescu’s picture

amateescu CreditAttribution: amateescu commented
Status: Needs work » Closed (duplicate)

Agreed with #12, let's close this as a duplicate of #1191438: file_usage not updated after removing a file/image field.

Leeteq’s picture

Leeteq CreditAttribution: Leeteq commented
Status: Closed (duplicate) » Postponed

Good to keep this one open until the core bug is fixed.
Then, if nothing needs to be adjusted in Media module after that core bug fix, then this issue can be closed.
Setting as Postponed, awaiting #1191438: file_usage not updated after removing a file/image field

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Postponed » Needs work

I'm not sure this is actually a duplicate of that particular issue. It's true that this problem will occur if a file field is removed from an entity type, but it will also occur if a file is simply removed from a node or swapped out if revisions are turned on. I personally believe this is probably an intentional feature in core so you can roll back a node to a previous revision complete with the image/file that was included in that revision.

That means that even after the file_usage bug is fixed there will probably still be old files in the system which are attached to old node revisions. If this is the case, it still seems that Media is going to have to basically filter these out of the Media Library view.

carole’s picture

carole CreditAttribution: carole commented

How can you trace where the image is used? Does 7.x.2.x.dev post the NID of the file where the image is used? I'm on 7.x-1.0-beta4.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The Media module doesn't currently expose this information as far as I'm aware. That information is in the database in the file_usage table, so it's possible to determine where a file is being used it's just not visible in Media module yet.

brunodbo’s picture

brunodbo
he/him
CreditAttribution: brunodbo commented

Could this be related to #911830: Can't delete any media item, because all are supposedly in use?

rgracia’s picture

rgracia CreditAttribution: rgracia commented

Subscribe

emptyvoid’s picture

emptyvoid CreditAttribution: emptyvoid commented

This may or may not be related but I get a notice and the following error when attempting to delete any file type with the media browser.


Warning: Invalid argument supplied for foreach() in form_select_options() (line 2595 of /var/www/ccof/code/includes/form.inc). Backtrace:

form_select_options(Array) form.inc:2571
theme_select(Array) theme.inc:1044
theme('select', Array) common.inc:5728
drupal_render(Array) common.inc:5735
drupal_render(Array) common.inc:5735
drupal_render(Array) common.inc:5801
drupal_render_children(Array) system.module:3960
theme_confirm_form(Array) theme.inc:1044
theme('confirm_form', Array) common.inc:5728
drupal_render(Array) common.inc:5735
drupal_render(Array) common.inc:5827
render(Array) page.tpl.php:28
include('/var/www/ccof/code/themes/seven/page.tpl.php') theme.inc:1397
theme_render_template('themes/seven/page.tpl.php', Array) theme.inc:1087
theme('page', Array) common.inc:5728
drupal_render(Array) common.inc:5591
drupal_render_page(Array) common.inc:2582
drupal_deliver_html_page(Array) common.inc:2470
drupal_deliver_page(Array, '') menu.inc:532
menu_execute_active_handler() index.php:21
fonea’s picture

fonea CreditAttribution: fonea commented

you could try this :
~~~~
$entity = entity_load_single($entity_type, $entity_id);
$entity->field_image = array();
entity_save($entity_type, $entity);

where 'field_image' is the field Name.
~~~~

thanks.

Rontero’s picture

Rontero CreditAttribution: Rontero commented

What I'm about to post is not the best solution. It might work for some people, though.

My setup: drupal 7.12 with 50+ modules installed (so thers is no point in lisiting them). The one, I thing makes all the difference, is File Lock.

Using media and media browser plus I uploaded many pics which were then linked to taxonomy terms. Later on I locked them with previously mentioned file lock module.

Since I didn't need those photos any more I had to delete theme. Shortly after I encountered problem described in this issue. Deleting terms did not let me delete pictures. However, for some reason after unlocking them I was able do actually delete them. I kept getting errors, but still, the process worked.

drupwash’s picture

drupwash CreditAttribution: drupwash commented
Status: Needs work » Needs review

#10: 1240834_10_media_forced_delete.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1240834_10_media_forced_delete.patch, failed testing.

dimitriseng’s picture

dimitriseng CreditAttribution: dimitriseng commented

I have the same issue, is there a proper patch or do we still need to wait on the core patch? Is this only for media 2.x or is this going to be backported to 1.x? Thanks.

arthurf’s picture

arthurf CreditAttribution: arthurf commented

This thread: #1268116: WYSIWYG does not record file usage attempts to handle the file usage for node deletion and node revision deletion. If this issue persists we should look at the file_usage table to see what modules are blocking the delete.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Priority: Major » Normal
Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Related:
#1968442: RFC: How to prevent files from being deleted by file/media fields when unused

desiboli’s picture

desiboli CreditAttribution: desiboli commented
Status: Needs work » Needs review

10: 1240834_10_media_forced_delete.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 10: 1240834_10_media_forced_delete.patch, failed testing.

The last submitted patch, 10: 1240834_10_media_forced_delete.patch, failed testing.

Chris Matthews’s picture

Chris Matthews CreditAttribution: Chris Matthews as a volunteer commented
Issue summary: View changes
Status: Needs work » Closed (outdated)

Closing this issue as outdated. However, if you think this issue is still important, please let us know and we will gladly re-open it for review.
sincerely,
- the Drupal Media Team