Hi,

I've found out that file usage is increased incorrectly when saving new revision of the node. It happens because of call field_attach_update and passing node with revision flag equal to 1.

The fix is easy but i wasn't able to do it for the latest dev version, it seems not working, because of incorrect condition in the select query from the filefield_paths table.
When field settings are saved, only content type name is saved in the "type" column.
But when module tries to process it later it looks for key "$type::$bundle". Because of that files are not processed.

Please review the patch and consider updating module if the code is relevant.

Thanks,
Dmitry

CommentFileSizeAuthor
#3 revisions-handling-1334448-0.patch710 bytespianodavid
unnecessary-revision-for-fields-removed.patch682 byteszhgenti

Comments

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Active » Reviewed & tested by the community

Hi Dmitry,

Your patch looks good and I do remember confirming and fixing this issue in D6 so this fix (or similar) will be in the next Dev release.

Cheers,
Deciphered.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Strike that last status, I wasn't able to reproduce this issue and therefore I don't want to commit anything unnecessarily.

Can you please provide more information (using the latest dev) on how to reproduce this issue? The patch you provided was clearly quite old as it was referring to $node, where the latest dev should have no reference to $node, only references to $entity.

Cheers,
Deciphered.

pianodavid’s picture

pianodavid commented
Title: Revisions handling » File usage is increased incorrectly when saving new revision
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new revisions-handling-1334448-0.patch710 bytes

Reproduce like this:

  1. Install clean Drupal 7.10
  2. Install modules Token and FileField Paths (latest dev)
  3. Create content type and add existing field "Image: field_image (Image)"
  4. Edit the field's settings - under IMAGE PATH SETTINGS - in the field "File path" write "images" or whatever
  5. Save content type and add content of the newly created type: Upload an image in the image field and select to save new revision

When content is saved, look in the database table file_usage and you should find that the file you uploaded has count = 2. This should really be 1. This makes files uploaded this way impossible to delete from within Drupal (e.g. IMCE) because even if you delete all revisions that uses the file, the count in file_usage will still be at least 1 and Drupal thinks that something is using the file.

I made a patch based on Dmitry's, but against the latest dev. This patch works for me.

(This is the first patch I posted to drupal.org, yay!)

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Needs review » Fixed

Issue confirmed, patch is (mostly) good and committed to 7.x-1.x.

Cheers,
Deciphered.

Status: Fixed » Closed (fixed)

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

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Closed (fixed) » Needs work

Re-opening this issue, the fix no longer works, as the count still gets incremented incorrectly even with this version of the patch or the current code in the module, and it's responsible for other issues in the module, so the code will be removed until a correct fix can be found.

braindrift’s picture

braindrift commented
Issue summary: View changes

Hi, is there any work on this?

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Needs work » Fixed

Issue fixed by change made in #1481260: Duplicate entries in in forum_index table.

Status: Fixed » Closed (fixed)

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