file field path set to static path publications
file renamed with [node:title].[file:extension]
cleaned up using path auto
1. initially when I add file and hit upload
origional named file is uploaded to server e.g. test.pdf
then I press save; file test.pdf is renamed correctly to the title of node and origional file extention
e.g. test-publication-6.pdf
2. When I edit the same node and remove content type then upload another file it uploads the origional named file test2.pdf to server (now has test-publication-6.pdf and test2.pdf). When I hit save it removes test-publication-6.pdf and renames test2.pdf to test-publication-06.pdf. This name is incorrect, it should be test-publication-6.pdf.
3. if I repeat step 2. I now have a file with the correct name test-publication-6.pdf.
This bug is causing major inconsitancies with file names.


Category:bug» feature
Priority:Major» Normal

I don't necessarily consider this a bug, as I would consider that overwriting my existing files is more damaging.

However, I do believe the behaviour should probably be configurable by the user, so for the moment I will change this issue to a feature request.

Right now my priority is to bugs rather than new features, but I will try to get back to it in the future, otherwise feel free to submit a patch.

Status:Active» Needs review
new10.6 KB
new30.3 KB

This capability is also important to me. Note that -beta3 did replace files (it passed FILE_EXISTS_REPLACE to file_move), and -dev has removed it.

I've attached a patch that provides a configuration option that will allow files to be overwritten. Screenshot also attached.

A much larger development here is the inclusion of tests. I've added a test for this new "replace files" option, and in doing so also created a few utility methods that should make adding additional tests a snap. Now I can sleep at night :)

Status:Needs review» Needs work

Expanded tests to check node object. Something not right - working on it.

Tests need to be rewritten completely, and your issue does not cover that scope, so please rewrite your patch to only deal with your issue and not try to re-implement tests.

There is quite a bit of uncommitted code related to the tests, so anything you do in that realm is likely just going to be blown away at a later date,

Look forward to reviewing the updated patch.

Status:Needs work» Needs review
new20.32 KB
new1.11 KB

Please ignore my previous patch, I've come to the conclusion that it's the wrong approach and that the issue described by the OP is indeed a bug.

To illustrate the problem, I'm going to change the OP's scenario slightly

  1. Create a content type with a file field.
  2. Configure file field paths to rename file to something that would be easily duplicated. I've tested all of the following, but the last one (although useless) gets the point across:
    1. [file:ffp-name-only-original].[file:ffp-extension-original]
    2. [file:ffp-name-only-original].[file:ffp-extension-original].processed
    3. constant_file_name.ext
  3. Attach a test file to a node, which will be processed and saved as constant_file_name.ext
  4. Edit that node:
    1. click "Remove" beside your uploaded file
    2. upload the test file again
    3. click "Save"

At this point, the file will be saved as constant_file_name_0.ext, instead of constant_file_name.txt. The issue here is that the system does not know that the user removed the file prior to uploading a new one. During the file_move() operation, Drupal should have recognized this and not incremented the file name (the magic lives in file_field_update()).

The bug is with the way filefield_paths_entity_update() sets the $entity->original property. It needs to be set before we get to the file_move() operation.

Attached patch is pretty straight forward. After we do the _field_load calls, and before process the file paths, we set $entity->original.

A separate attachment is my Simpletests, which tests all of the File Name patterns mentioned above.

I had senario 3 (constant file name). File being created at the end of a batch process. On the initial entity save I got "myfile.ext", on the second save I got "myfile_0.ext", on subsequent saves the file name flipped between these two. Patch in #5 applies cleanly and fixes this issue against 7.x-1.0-beta3.


If you do step 3 and 4 without File (Field) Paths installed the exact same behaviour will happen, the new file will have the _0 appended to the file, whereas if you remove, save, then re-add the file for both with and without File (Field) Paths it won't append the _0 to the file.

The reason this happens is that when you remove a file it's not actually removed until after the content is saved, so it is somewhat the expected behaviour.

However, I haven't looked at your proposed patch properly yet, so I'm not entirely ruling out some changes for this functionality yet.


That's a good point - I didn't realize that the stock Drupal file field behaved this way.

The history is in the cck filefield module:, where quicksketch makes his point clear in comment #1. This patch, however, does work in the scenario he describes. If a user uploads file.ext, it's saved as file.ext. If they edit the node, click "Remove" and re-upload file.ext, it is uploaded to the filesystem as file_0.ext. *Only if* the user saves the node, does it get renamed by filefield_paths to file.ext (and file_managed table updated). In other words, if the user abandons the node edit form after clicking 'remove' and uploading again, there is no harm done.

I'm just now running into this but in a different way.

I work at home on my laptop. I have a local install exactly matching that of my live site. When I create a 'work_sample' content, I click on the Choose Image and navigate to the file in the local drupal install which ends up: /sites/all/themes/my_theme/images/samples

So inside that 'samples' folder are all my jpegs. On the live server, I have the exact same structure: /sites/all/themes/my_theme/images/samples and I've already uploaded all the samples. Locally, all works as expected. When I dump the sql file and reimport to the live site, the images get a _0 added.

Since I'm choosing files within the Drupal install and both installs are identical I don't know why the renaming is occurring especially since I'm not actually 'uploading' anything. If I ftp into the server, nothing has changed in the filename. And, before importing the database into the live site, the paths and names are correct.

I thought I could go in phpMyadmin, find the reference and change it there but this new site is on GoDaddy so within phpMyAdmin, browsing tables isn't allowed.

Simple thing though a little more laborious: ftp to server.. add an underscore to images in question. Re-upload image via the Drupal inteface. Fixed. Then, it's easy to just delete all the old files with the underscores.

I tried patch #5 but am still having issues. I have a feed importer adding images to a field that has file field path applied to it. If it comes across a duplicate image it appends_# to the end of the file name and continues on it's way. I'd really just like to skip any duplicates. Any way to do this?


A straight ugly temporary solution on beta4 is to add FILE_EXISTS_REPLACE to file_move in filefield_paths_filefield_paths_process_file in and use a patch with feeds that allow you to setup the file replace and file rename choice, see

You still need to add $entity->original = $entity; to filefield_paths_entity_update in filefield_paths.module

A better one is to run this hook before in your own module (my_module_filefield_paths_process_file).

I aslo would consider a good thing to set the file behavior to be configurable, for migration purpose at least (not a most wanted then). Rename is the drupal default, feeds could be configurable (not released yet) but this setting is unknow to filefield_path.

Category:Feature request» Bug report
Issue summary:View changes

Just ran into this issue with Migrate module migration. When I run the migration update (drush mi --all --update) all files flip between the original filename and the _0 filename resulting in 100k image and 200k image style 404s. I'm looking into a good solution.

Status:Needs review» Needs work

The patch in #5 fixes the problem although only the first hunk is needed, so the patch needs work to apply cleanly. I'll RTBC if the patch is fixed to apply to the current dev. Thanks!