This is a duplicate of https://www.drupal.org/node/2045611 since that issue is closed and can't be reopened.

Steps to reproduce:

  1. Navigate to the files listing from admin menu
  2. Select Edit for the file that needs replacement
  3. Use the Replace File field, and and select the new file
  4. Save the old file

On the files listing, the file you hoped to replace APPEARS TO remains unchanged -- same file path, same file ID, same usage, still marked as permanent.

However, on the files listing there is now ALSO a new entry for a new file -- with a new file path, new file, ID, no usage at all (and the new file is marked as temporary). This new entry has the filename and file path of the file you just added.

This is confusing to users because it appears as though the change you just made did nothing, and instead a new record was created with the information you wanted in the old record. In reality, the old record was, in fact, updated, but the addition of the new temporary record makes it seem as though something has gone wrong.

Comments

jenlampton created an issue. See original summary.

jenlampton’s picture

Title: Replacing a file leaves an unwanted temporary file that duplicates the replaced file » `Replace file' leaves the original file entity unchanged, and creates an unwanted temporary file instead
jenlampton’s picture

Issue summary: View changes
jenlampton’s picture

Title: `Replace file' leaves the original file entity unchanged, and creates an unwanted temporary file instead » Replacing a file creates an unwanted temporary file with the new filename and path
Priority: Major » Minor
Issue summary: View changes

Hm, I misunderstood what was happening with the file replacement because the experience of seeing the new temporary record threw me off. Updating ticket label, description, and severity to match the user experience issue.

joseph.olstad’s picture

Yes it is a configuration dilema for existing installs, if my grey matter memory about this is still valid the file paths pattern is only different behavior for new fresh installs.

I didn't want to impose a config change on existing installs in case that config was relied upon or expected by the site builder.

We can maybe see here about proposing some new g.u.i option that would give option on this however it has been over 2 weeks since I looked at this so I'd have to look closer at this and in no hurry about it.

alison’s picture

I think also that these temp files go away, IIRC... did that happen in your usage, Jen, now that it's been a few days?

kmonty’s picture

Experiencing similar issues. Oddly wasn't experiencing the problem with -beta3, but rolling back the codebase didn't resolve the issue.

joseph.olstad’s picture

a few commits have been put int dev, might be worth re-testing.

drupal-son’s picture

Hi,

Same issue here.
I updated to the latest version 7.x-2.3 (released yesterday) where all those new commits should be merged.
No difference.

When replacing the file, the old one gets replaced but a new entry is created with the /system/temporary/filename.ext path.
I can notice that the file ID are not the same, the new file gets incremented.

If I upload the same file as a new file, then a /filename_0.ext is created as a new file entity.
I remember I applied an old patch which renamed the existing file with the N+1 and keeps the original name for the new uploaded file. Is this the expected behavior when uploading duplicated files?

Thanks.

drupal-son’s picture

Running cron doesn't remove the temporary marked file entities.

In the meantime, as a workaround, this is what I did:

I created a new version of the /admin/content/file view where I'm showing a few more fields, exposing some filters and filtering out the status marked as temporary entities.
This way, I'm showing to my users only the permanent files avoiding confusion to them and at the same time giving them a few more tools to manage the files on the website.

It seems that the Media Browser (the LIBRARY tab) is also filtering out the files marked as temporary, so that is consistent of what I'm showing to my users on the new /admin/content/file view.

Regarding the other question about the new (but duplicated) file name behavior, I would like the new file to be handled as a replacement file of that file name.

Thanks.

estepix’s picture

Did anyone have a look at the patch I submitted here?

https://www.drupal.org/node/2045611#comment-12112131

I'm currently using it in a site and it seems to work well, not sure if this is the way to go though, after reading comment #5

loziju’s picture

Version: 7.x-2.2 » 7.x-2.3

@estepix the patch in https://www.drupal.org/node/2045611#comment-12112131 does not work for me. That piece of code is already inside 7.x-2.2 and 7.x-2.3.

I confirm that the issue still happens on 7.x-2.3. Updating the issue metadata to that version.
I also have media 7.x-2.9 installed, although I don't think the issue comes from media.

lindakosta’s picture

We're on 7.23 and we're having the same issue. When we first upload a replacement file, it replaces the file, but the file name renames the same even though the replacement file has a different name. The temporary file is created and eventually goes away, and the permanent file eventually is renamed using the replacement file name.

We also have the media module (7.2.3) installed. We also installed media 7.x-3.0-beta4 and continued to experience the same issue.

fskreuz’s picture

Patch ensures that after successful replacement, the temporary file is deleted.

stephaneq’s picture

Status: Active » Needs review

Hi,

Tested your patch, it seems to fix the issue for me. Thanks.

joseph.olstad’s picture

Patch looks good thanks!

  • fskreuz authored 92781f5 on 7.x-2.x
    Issue #2887487 by fskreuz: Replacing a file creates an unwanted...
joseph.olstad’s picture

Nice job @fskreuz!
Munga tuk

joseph.olstad’s picture

Status: Needs review » Fixed

committed to 7.x-2.x dev
Haven't decided yet when to tag the next release though, might be worth a tag for just this fix. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

estepix’s picture

I just tried version 2.4 and it's working alright! thanks everyone!

joseph.olstad’s picture

Success! Thanks for reporting.