Drupal 6.10;
CCK version 6.x-2.2;
FileField version 6.x-3.0-rc1;
ImageField version 6.x-3.0-rc1;
Apache under Windows runs with unlimited permissions.

I dunno whether this is an ImageField problem or some other module problem (FileField?) or a configuration issue. I hope you'll help me anyway. ^_^

How to reproduce:
1) Create a node with an imagefield, upload an image.
2) Edit the node, select another image to upload.
3) Now both images are uploaded to server. You can see them both when viewing node revisions.
4) Delete the node.

What happens:
The later file gets deleted from server. The earlier one remains and, i think, becomes an orphan, a dead weight wasting server disk space.

What i suppose should happen:
All files associated with the node should be deleted.

I've searched for filename in my DB and found that the orphaned file is mentioned in the "files" table. But its "fid" is not mentioned in the "content_field_" table (whereas other files' fids are mentioned there).

Please help locate the problem's source and solve it. If it's necessary, i can repost the issue into another module's issue queue.

PS I also use the Image crop 6.x-1.0-beta3 module, but i'm sure that it's not the one to blame 'cause files generated by Image crop follow the same pattern: get deleted if they are from the latest revision and remain if they are from a previous revision.

Members fund testing for the Drupal project. Drupal Association Learn more


quicksketch’s picture

Project: ImageField » FileField

Thanks for the excellent bug report. I haven't confirmed the problem, but as you describe it sounds likely. Currently our implementation that deletes files on node delete seems to only check the last revision for file use. I think this is probably because we had assumed that it was called for every revision, but this doesn't seem to be the case.

Once we fix the problem, we should also update our revision testing suite, which should account for this situation.

This problem also affects FileField, so I've moved it over to that queue.

quicksketch’s picture

Status: Active » Postponed (maintainer needs more info)

I think this problem may have been fixed since the RC1 release. I tried the workflow you described, but I couldn't get any file to become "abandoned". It was always deleted from both disk and from the files table. Could you try out the CVS or development version and see if you can reproduce the problem from there?

quicksketch’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Closing after lack of response. This problem does not seem to exist in the 3.0 release.

markDrupal’s picture

Title: Orphaned files. If you re-use an imagefield and then delete a node, the older image will not be deleted. » Orphaned files. If you re-use a imageefield (or fieldfield) and then delete a node, the older images will not be deleted.
Version: 6.x-3.0-rc1 » 6.x-3.2
Status: Closed (fixed) » Active

I'm finding this problem is still leaving orphaned files for me with version 3.2 of filefield.

I created 3 images all with the same name, 1.jpg saved in different folders, then began my test.

1. Create a new node with a single file field. Only one file allowed per node.
2. Upload an Image, 1.jpg, click save
3. Edit that node
4. Click 'Replace' to replace the file, select the next image file 1.jpg, upload save
5. edit the node again, repeat step 4
6. Check my file directory, confirmed 3 new files: 1.jpg, 1_0.jpg, 1_1.jpg.
7. Confirm 3 revisions on the node by clicking the revision tab
8. Click edit tab, click delete button, confirm delete
9. Node is now deleted, checking file directory, 1.jpg is also deleted
10. Remaining after the delete are files 1_0.jpg, 1_1.jpg
11. Also remaining after the delete are 2 rows in the {files} table that point to the files 1_0.jpg, 1_1.jpg

So I'm left with orphaned files when using node revisioning & delete a node.

Dirk’s picture

I can confirm MarkDrupal's problem, a big problem in my case, and it affects all file types. Filefield is simply refusing to delete files from de default/files/x folders, this is a bad situation. While i was searching for a solution i ran across several threads with, what seems to me, the same issue from a year ago, all marked duplicate or fixed. Did something go wrong with my module at some point (bad upgrade or something like that) or was that bug never properly fixed?

quicksketch’s picture

Hmm, we actually have tests that confirm this exact problem doesn't exist, though perhaps there's a difference from your workflow versus what the test does.

Regarding your last point:

11. Also remaining after the delete are 2 rows in the {files} table that point to the files 1_0.jpg, 1_1.jpg

Are these files marked as "permanent", that is, is the "status" column = 1? If status is 0, these files are automatically cleaned up after 6 hours by cron. This can occur when you upload a file, remove it without saving the node, then upload a different one. In which case the file never is saved into the FileField tables and the file is never associated with the node, so deleting the node does not immediately delete these files.

Dirk’s picture

So is there any way to solve this problem? The fact that files are being renamed can be a real problem in my case. The entries for the _# files all have status 1 BtW, so nothing is being deleted, the files folder and its subfolders are merely becoming ever messier.

quicksketch’s picture

mcarbone’s picture

Version: 6.x-3.2 » 6.x-3.7
Status: Closed (fixed) » Active

I am experiencing this problem, and am having a hard time debugging it. Can I ask where in the filefield code files in old revisions are deleted? As far as I can tell, only filefield_field_delete is called when a node is deleted, and that function only ends up deleting the file in the current revision.

mcarbone’s picture

Version: 6.x-3.7 » 6.x-3.x-dev

Just tested this on the dev branch with a fresh install and I'm still having the issue. Steps to reproduce:

1) Create node and upload file test.pdf.

2) Edit node with "create new revision" and remove file.

3) Edit node with "create new revision" and upload file test.pdf (gets renamed to test_0.pdf).

4) Delete node.

Verify in database and file system that test_0.pdf is removed but that test.pdf is left orphaned.

mcarbone’s picture

Status: Active » Needs review
1.05 KB

Here's a patch that explicitly deletes the items from former revisions. Seems to be working for me.

introfini’s picture


quicksketch’s picture

Title: Orphaned files. If you re-use a imageefield (or fieldfield) and then delete a node, the older images will not be deleted. » Files from previous revisions (but not in latest one) are not removed on node delete
Version: 6.x-3.x-dev » 6.x-3.7
Status: Needs review » Fixed

Thanks mcarbone for the patch and review. Following your steps I could definitely reproduce the problem. I think this isn't necessarily a problem with a re-used file, but really with any file that isn't included on the last revision.

I tested out the patch and it looks good. Committed and it'll be in 3.8.

Status: Fixed » Closed (fixed)

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

hanoii’s picture

Version: 6.x-3.7 » 6.x-3.10
Status: Closed (fixed) » Needs review
614 bytes

I believe I have found a bug in the committed code. By not setting also the deleted nid besides the deleted vid, hook_file_reference() sometimes returns a count even when it shouldn't.

For instance, say you have one node with a filefield, you then change some other field and save it (filefield remain the same), then you changed the filefield.

So you have three revisions, the two oldest have the old file, however, as those are covered by this code, when hook_file_reference is called, it returns a count, because those items (the one in the revision) were not flagged as being 'node' deleted.

quicksketch’s picture

Could you describe when a file would (or would not) be inadvertently deleted in the scenario you've described?

hanoii’s picture

Sure, I tried to lay it out. I should note that I noticed this by debugging an import with node_import (as I am developing some extras for it), and while trying that and removing what I was importing I noticed this, but I just tried on a new node and it's the same

1. create a content with a file
2. create a new revision of that content by changing some other text field (node title for instance), in order for the new revision to have the same file
3. create another revision with a new file replacing the previous one
4. Remove the node altogether.

When you do this, w/o the patch, the old file is not removed because it's on two revisions, thus, hook_file_references() which calls filefield_get_file_reference_count() which only looks to substract references from the node being deleted, which should be flagged when removing revision files on node delete.

quicksketch’s picture

Thanks, I appreciate the new steps. There's also #1210710: File deletion not handling deletion of previous revisions correctly which has to do with revisions not being handled quite properly, I wonder if both fixes are necessary in conjunction.

We've got some tests to check for this sort of thing, amending them to handle this use-case also should prevent it from being a problem in the future.

shadysamir’s picture

Id doesnt seem like anyone is working on this. It just broke my site today, Was very difficult to track and relate to this issue.

quicksketch’s picture

Status: Needs review » Fixed

I've confirmed that #1210710: File deletion not handling deletion of previous revisions correctly fixes this problem without the additional patch from #15. Using the steps from #17, the problem no longer exists now that the other patch has been committed. I rolled the patch back, and the problem reappeared. So as far as I can tell, no further work is necessary here.

Status: Fixed » Closed (fixed)

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