Replacing a file leaves an unwanted temporary file that duplicates the replaced file

What are you doing to perform the file replacement? This isn't at all how the file replacement functionality actually works so I just need to know a bit more about what you're doing.

@plinto - I was also a little confused at first. This is also how my setup works. If you look at the file paths of the two files, the one that got replaced will show a temporary://something.pdf.

Those temporary files will be deleted by cron after 6 hours I think.

@Dave Reid - maybe we shouldn't show temp files in the files tab? Maybe it would help eliminate some confusion?

plinto - If the older file still has usage, then it won't be deleted. Check the usage link on admin/content/file for both files(old one and new one) and see if it has any usage.

Something else may be using the old file. Could be a node revision or a file field using the file?

Similar issue #2032009: replacing media item with a new file updates the initial fid, but also creates a secondary file

file_entity_edit_validate() saves the replacement file, and file_entity_edit_submit() then copies the replacement file over the original (using file_unmanaged_copy), but I can't see where the temporary replacement file is meant to be cleaned up. Should there be a call to file_delete() after the call to file_unmanaged_copy() in file_entity_edit_submit()?

No, we don't need to be responsible for removing the temporary upload file because the system is supposed to take care of that for you. I suppose we could use file_unmanaged_move() instead of file_unmanaged_copy() though.

It seems like the file itself is being cleaned up, but an entry is being left in the file_managed table.

This shows up at admin/content/file and is also causing PDO errors when trying to upload a file with the same filename (which should probably be filed as a separate bug anyway).

I'm seeing this behaviour and it confused both me and my users. We shouldn't be displaying temporary files in the file overview in my opinion. Note: This can be worked around by adding a filter to the admin view to exclude files with paths that start with temporary://

I followed the same steps as #2.

I'm using Media 2.x-alpha2 and the original file remains in the media root, attached to nodes, etc. The file I'm trying to replace it with is actually being moved to tmp to be deleted by cron. So, the old file stays in place, and my new file is moved directly to tmp.

This is backwards of what we're intending to do here, right?

Before the upgrade to Media and FE 2.x, we were using the filefield_paths module. That module was uninstalled before we updated. The way my files are placed in the filesystem makes it clear that filefield_paths obviously isn't doing anything anymore (it's all dictated by Media settings now).

It's also worth noting that I'm using brightcove_media and media_internet.

RE: #10

@ianmthomasuk, I cannot reproduce that problem, using identical file names. Instead, I get two files with the same name, with the replacement file uploaded into /tmp. The original file remains in place on the nodes. The file browser at admin/content/file shows two files with the same name, but different URLs.

So, my issue, I believe is related to this thread. If you're getting a PDO exception from duplicate file names, then you should open a separate issue. Please post a link to that here.

RE: #11

I have created a separate issue for this. #2099913: Files in Temporary Folder Should Not Be Displayed at /admin/content/file

The issue above has been closed in favor of #2028089: Too much restriction for temporary files. I submitted a patch there which fixes the temp files issue described in comment 11 here.

Had robeano run into this today and reviewed the replacement code again, and there definitely is a problem leaving the temporary file around if the replacement was successful.

I am able to replicate this issue as described in comment 2.

* Select Content from admin menu
* Select the Files tab
* Select Edit for the file that needs replacement
* Select Replace File and select the new file
* Save

Two files appear in /admin/content/file: the original and the file I just uploaded to replace the original. As stated above in comment 9, Core will remove these temporary files. Having to wait 6 hours for the removal of temporary files causes confusion for site administrators and editors.

If the file is successfully replaced, then the temporary file should be deleted immediately.

Here's my first stab at the fix, which is one line of code and a bunch of changes to our tests to assume that the default files are not temporary, so that this is easier to test if a temporary file exists or not. It passes my local install so let's see if it passes the bot.

Let's try this one to fix the file access tests.

Tests were failing when testing file access. By default view permission for public permanent file is set to TRUE. In the test, since we are testing trying to view access to a file without this permission, we now remove it in the setUp function of the test

Thanks everyone! Committed to 7.x-2.x.

I can reproduce this problem again in current version 7.x-2.0. It seems that some code from this other issue:

https://www.drupal.org/node/2112491

has been ported to current 2.0 version, especifically:

    if (pathinfo($replacement->uri, PATHINFO_EXTENSION) == pathinfo($file->uri, PATHINFO_EXTENSION)) {
        file_unmanaged_copy($replacement->uri, $file->uri, FILE_EXISTS_REPLACE);
    } else {

on function file_entity_edit_submit, file file_entity.pages.inc

I wonder if this could be reverted to its previous state since the feature requested in #2112491 does not seem to be implemented. I can provide diff with the relevant changes, however not sure if I should attache a patch file here or any other way.

Regards,

Sending patch

I am also still seeing the behavior described in #2 in the 7.x-2.2 version of file_entity. It was also happening in 7.x-2.1. Unfortunately, it looks like we can't reopen this issue. Should I open a new one?

edit: here's a duplicate issue: https://www.drupal.org/node/2887487

FYI: https://www.drupal.org/node/2887487#comment-12200833 fskreuz's patch fixes the problem and it has already gone into v2.4 of the module.