Currently in drupal 5.x, if you attempt to update a picture on a page (call it pic.jpg) by reattaching it (re-uploading it), drupal will rename it to pic.jpg_0, then pic.jpg_1, and so forth. Unless you go "behind the scenes" and see this behaviour for for yourself, you would never know that this is happening and it would appear as if drupal had completely ignored the upload as it continues to use the original image.

In my opinion, the following suggestions might help to make this a little better. I have listed them in order of robustness:
- add a confirmation "Do you wish to replace PIC.JPG dated X with PIC.JPG dated Y?"
- replace without confirmation and move the *old* version to PIC.JPG_0, PIC.JPG_1, etc.
- refuse to accept a file PIC.JPG while a file of the same name still exists, forcing the user to delete the old version before proceeding
- in the very least, tell the user "You must use the file name PIG.JPG_9 if you want to see your new image"

Thank you for your attention.

Comments

vm’s picture

vm commented
Version: 5.7 » 7.x-dev
Category: bug » feature

moving this to a feature request of next version being developed.

drewish’s picture

drewish commented

i don't know if i understand why this is needed. if you delete the existing file, save the node then re-uploaded it you'll be fine...

walker_643’s picture

walker_643 commented

This is needed because the delete checkbox in the File Attachments box does not delete the file; it simply removes it from the list. When the user then uploads a file of the same name (presumably a newer revision), drupal will still be linking to the older revision of the file. In the case of the file being an image displayed on the page, the user will still be looking at the old image.

bigdave’s picture

bigdave commented

it seems to depend on if the node has "create new revision" checked or not.

If no, deleting the file, save the node, re-uploading same file works.

But if set to yes, and you do the same, the file gets _N appended.

Is this a bug with creating revisions? Does it need to somehow change the file names of "changed/deleted" files in conjunction with the revision?

(EDIT: Changed verbiage to properly reference revision and not version)

walker_643’s picture

walker_643 commented

Thank you for following up on this posting.

For the next version, whatever your solution, please make it clear to the user what action the cms is taking. If you will be renaming files instead of replacing them, can you give users a choice: "Drupal needs to rename 'blah.png' to 'blah.png_1' Would you like to 1) Let Drupal update my links to this file 2) Manage links myself". Or, at least, report that "Drupal has called your file 'blah.png_27' to reflect the updated revision. If you wish to use this revision of the file, please ensure that all of your links are up-to-date with the new filename".

Also, it would be nice if there were an easier way to perform maintenance on the drupal files. I realize this is really a separate feature request, but I mention it here because it coincides with the topic of this posting. If we had both a clear indication of what name uploaded files were given, then were told whether a file was being replaced or installed beside its predecessors, and we had a sort of file management interface, this sort of daily/weekly maintenance would be much simpler. We might see from the file management tool that there are 8 copies of blah.png (called blah.png_1, blah.png_2, etc.) and only blah.png_7 was referenced from our drupal site. Or, maybe, that there was still a reference to blah.png_2 from this.html page, so we correct that reference, then delete the outdated copies of the file.

At the moment, I maintain a single drupal site. Even on this one site, it can be challenging at times to keep up with a pool of users that don't really care how much disk space they're wasting, and take issue with having to change their pages when they upload a new copy of an image ("But it's the picture I changed, not the page"). I do appreciate any effort you give my request.

Thank you.
Ian

Susurrus’s picture

Susurrus commented

@walker_643: File upload administration is being worked on here: #25756: Enhanced file administration

bigdave’s picture

bigdave commented

I just installed Upload File Replace (for filefield CCK) (http://drupal.org/project/upload_replace) and it seems to handle this problem for me. Basically it takes what would be the "updatedfile_N" file in the current version and swaps it with the "updatedfile" that exists in the previous revision.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (won't fix)

Upload module has been removed from Drupal 7, and no features are being accepted into 6.x. Closing.

markshust’s picture

markshust commented

There is still a bug in this ticket. Deleting an attachment from a node that doesn't have revision tracking enabled deletes the file from the filesystem, while deleting an attachment from a node that does have revision tracking enabled doesn't delete the file from the filesystem.

markshust’s picture

markshust commented
Version: 7.x-dev » 6.16
Status: Closed (won't fix) » Active

Forgot to reopen ticket. Changing it to version 6.16.

markshust’s picture

markshust commented
Category: feature » bug

Moving from feature request to bug.

drewish’s picture

drewish commented

markoshust, that actually sounds like the correct behavior. if you have and old version you don't change that, you only change the current version. so why would you remove the old file?

mdupont’s picture

mdupont
Primary language French
Location Switzerland
commented
Status: Active » Closed (works as designed)

Old issue and sounds like the correct behavior to me too. Closing.