1. create a file field on Article let allowed audio file type.
2. Create a new article and assign an mp3 to the file field (Add media), then save it.
3. Edit this article again and click remove media, and then save.
what I understand is only the reference to the mp3 file is removed, but when I check media collection again, I found out that my mp3 file has gone?
And it's weird that this seems to happen only on audio file? if you repeat the 1,2,3 with and image file, the file is still there and everything is OK.
Any idea?


Dave Reid’s picture

Status: Active » Closed (cannot reproduce)

I cannot confirm this. I tested with an audio-enabled file field + media browser widget with the exact same procedure and it did not delete the file record in {file_managed} at all - so I was able to select it in my media browser the next time.

csunny’s picture

Status: Closed (cannot reproduce) » Active

Do little digging and find that:
After I upload mp3 or ogg files, there are no records been insert into file_usage table about the uploaded file. But the uploaded image file did have records in file_usage.
Is it possible that this cause the problem?

csunny’s picture

correction: I found out that all the files uploaded by media browser has no records been inserted into file_usage table (including image). The only image which have record maybe uploaded by other module (maybe core image module, I don't remember clearly) so it has not been deleted after I click "Remove Media".

And I see the file_field_delete_file function delete the file when I click "Remove Media".


Dave Reid’s picture

Status: Active » Postponed (maintainer needs more info)

Hrm, so file_field_delete_file() is called from file_field_update() which is called when the file field's original fid doesn't match the new fid value.

The important part is this file deletion is skipped if your file is not a temporary file. Which you've indicated in your case your files are in fact temporary (which is odd because mine upload as public files and not temporary). What are you using to upload the files? The media browser upload tab?

csunny’s picture

Yes, I think I upload file using media browser upload tab. But I will confirm this tomorrow morning.

csunny’s picture

Okey, let's start over.

case 1:
1. create the file field on article type and allow audio type file.
2. create an article and click "Select Media", then USING "Upload Tab" to add a mp3 file. Save the article. Then we can see both file_managed and file_usage have record. file_usage have record that module:file; count:1
3. edit the article and click "Remove Media", then Save it. we can see the file_usage's record has been cleaned up as well as the file_managed's record(and also the file on the disk). I think it's because the file module find out that this file has no longer been used by any module and now it's a "temporary file" .

case 2:
1. add an media at admin/content/media using "add file" link. We will find that no usage record has been setup.
2. "Select Media" from media browser to attach the file to the file field of one article content. Okey, usage record has been setup.
3. "Remove Media" from this article and the results are the same as case 1.


csunny’s picture

Status: Postponed (maintainer needs more info) » Active
csunny’s picture

I am start to thinking that it sound like some kind of "work as design".

Should we consider the file delete strategy as:
if one add a file at admin/content/media, we should add an usage record as "using by media module"(it seems like the older media module has done this). So the "Remove Media" at content edit page will not delete the file according to usage record. Therefore the only place that can actually delete the file is only at admin/content/media.

Any idea?

idflood’s picture

I experienced the same behavior with images while trying to reproduce another issue. I was surprised that the images uploaded from the admin/content/media pages where deleted.
+1 for the idea of csunny in #8, it was what I expected.

gmclelland’s picture

I experienced the same issue. I had created a content type and added an imagefield with the widget set to "Media file selector". After I upload an image and save the node, the node displays fine. When I edit the node and choose "Remove media" from the imagefield the file is completely removed from the file system. I was just expecting the reference to be removed, not the whole file.

Let me know if you need anymore info.

gmclelland’s picture

FYI... This doesn't not happen when I test using the 2.0-unstable2 version, it only happens with the 2.x-dev

Hope that helps,

gmclelland’s picture

Disregard that last comment, after more testing this does happen with the 7.x-2.0-unstable2. Sorry

Dave Reid’s picture

Issue tags: +file usage
tsvenson’s picture

The reason this is happening is that when you upload the file (happens for any file using the File field) is that it gets registered as being used by the node. Then when you remove it, that use is also removed. Drupal will then trigger due to that the file use is 0 and automatically delete it.

This can have even worse consequences for a site. For images, if you embed one, using a WYSIWYG editor, those embeds are not counted. Then when the last file field it is used at is removed, Drupal will delete the file, despite it being used (embedded). See for a more detailed use case of this.

This is also bad considering that the Media/File Entity comes with a multi file import feature. Those imported files all have 0 in the usage table. Then if you add/remove it from a node, it will also be physically removed from the file system.

This behavior is in Drupal and as far as I understand it "works as designed". Thus its not a bug. However, since the user (content editors) are left without any control over this, I at least file it under "serious design flaw".

The only way I have found so far to avoid this happen is to make sure that you create a new revision when you remove a file from an existing file field. That way the old revision will still be listed as using it and it will never be deleted.

However, I haven't tested (yet) what happens if you add/remove a file without saving in between. My guesstimate is that it will be deleted.

Also see #1268116: WYSIWYG does not record file usage regarding a proposed solution for WYSIWYG.

Personally, I would prefer if the Media/File Entity would up the use count for any files added to prevent this. Then leave deleting any orphaned files to the editors/administrators.

I much rather have orphaned files lying around, than let Drupal bluntly decide when they shall be deleted.

Shuairan’s picture

In our company we had the same problem, Drupal deletes files which should not be deleted and there is no configuration to change this behaviour. So I started to work on an small module: Media_Lock

It 'locks' files by adding a file_usage entry linked to the module. Your existing files can be locked/unlocked via the file overview, with the additional options "lock selected files"/"unlock selected files".
In configuration settings Media->Media Lock you can choose how to act on new files.
More details on the project page.

Update: Module File Lock is now a full project

simonruffle’s picture

+1 for the idea of csunny in #8 from us.

This issue is a major showstopper for our use of this module.

Dave Reid’s picture

Cross-linking some references and possible solutions:
#1381726: File Lock
#1399846: Make unused file 'cleanup' configurable

rickvug’s picture

Thinking about this problem I'm not convinced that making file deletion optional is not the way forward. The issue is that the media browser is not declaring which files it cares about and should therefore be protected from deletion. Removing a file from a field and deleting said file in the process is a valid use case. Files such as a user's profile image may not be suitable for re-use and perhaps shouldn't be in the media browser because of this. As a solution to this problem, how about something along the following lines?:

  1. Move the concepts behind File Lock into the Media module in a simplified fashion, with the default setting being to protect all files. Media will record file usage across the board, solving this issue.
  2. Advanced site builders could then add patterns to a blacklist for files they don't want in the browser or protected against deletion. The logic could be defined based on a folder structure by default but ideally there would be a hook for other modules to define blacklisting logic. Certain sites may want to determine which files are available in the browser based on stream wrapper, file size or other criteria.
  3. Fix #1268116: WYSIWYG does not record file usage. WYSIWYG usage should be tracked aside from the Media browser so that files can be protected from deletion by Media itself if still in use.
  4. In this scenario, say a file as uploaded via a file field, was also used in a WYSIWYG editor via media and also was uploaded to a directory that the media module tracked. File usage would be declared 3 times: once by file for the node, once for WYSIWYG for another node, and a third time by Media generally.

camdarley’s picture

For information, file deletion happen when the node language is changed, file are removed from the field and physically... Thats pretty critical when files are important...
See #1141912: Changing node language by moving down language list deletes files in file field

RobW’s picture

Just ran into this with a client, and I agree it would be nice to have a locklist-like functionality added to Media, at least until the above-mentioned core issue goes through. I'm fine with either all files locked by default with module supplied exclusions or all files open by default with module supplied locks, as long as files uploaded with the media browser are locked. It's my experience that when someone adds a piece of media to their "library" there is an assumption of potential re-use.

Would a reasonable a quick fix by adding all files uploaded with the media browser to the file usage table under Media Module, maybe with object type of library?

agentrickard’s picture

RobW’s picture

Downloaded last night, and it solves the problem very well. Thanks.

Devin Carlson’s picture

Status: Active » Closed (duplicate)