• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item5384: Allow Delete of Duplicate Attachments

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine Manage Normal Closed TWiki:Main.GeorgeTrubisky patch 5.0.2

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


TWiki:Codev.ImproveAttachmentToTrashFlow was written by ArthurClemens who said (before I pointed the content to here)

When an attachment is deleted it is, by default, put into Trash.TrashAttachment. This causes problems if many users delete a file with the same name. It already causes a problem when 2 people have the same attachment, which is not so rare if they attach screenshots made on a Mac that are typically named "Picture 1", "Picture 2", and so on.

Feature Proposal: Improve attachment-to-Trash flow

This topic is currently held up on on impact, below, which essentially asks whether it is okay to change all behaviours where attachments are renamed. (Trash is implemented using the same mechanism as normal renames). Currently renaming an attachment is prevented in the event that an attachment by that name already exists. The proposal would make all such renames succeed, only have later items named from Oneweb.Firstopic.Attachment to Someweb.Sometopic.AttachmentNN where is progressively higher and as such does not conflict.

-- MartinCleaver


What should the user do?

  1. After having clicked attachment manage -> delete: leave the page and go to Trash Web
  2. Create a new page inside Trash
  3. Again go to the delete attachment page (2 steps)
  4. Type in the name of the newly created topic and submit
This is a pain.

The situation gets worse in a TWiki app if you simply want to delete an attachment. There is no way to get around above scenario, because:

  1. The topic must exist
  2. The attachment will not be renamed


TWiki stores all deleted attachments on Trash:TrashAttachment (Arthur did mention that duplicate attachments could be stored elsewhere but this is excluded in this revised proposal because it doesn't follow the pattern used for topics). I think we should use the same autorename scheme as used for topics to delete attachments that have already been deleted.


  1. Provide a system that simply doesn't give an error when a duplicate attachment is filed. Instead have it rename the duplicate to a different name.
    1. To optimise, it could delete an attachment that has both the same name and the same content
    2. It would be acceptable to fail when it tries to automatically restore an attachment back to the same name. (It would likely pick the first or last copy)
  2. Handle restores of attachments that had duplicate names
    1. Give a menu to the user which ones to restore
    2. Optionally only allowed to restore those attachments written by the current user.

Implementation Context

Trashing attachments is implemented in Manage.pm as a rename of the attachment from the current location to the topic Trash.TrashAttachment. It is currently considered an error to move an attachment to a page on which an attachment of the same name already exists, so TWiki prevents this happening by raising an exception. http://develop.twiki.org/svn/twiki/trunk/core/lib/TWiki/UI/Manage.pm line 332 (as of Feb 22, 2008)

if( $newWeb && $newTopic ) { TWiki::UI::checkTopicExists( $session, $newWeb, $newTopic, 'rename');

# does new attachment already exist? if( $store->attachmentExists( $newWeb, $newTopic, $attachment )) { throw TWiki::OopsException( 'attention', def => 'move_err', web => $oldWeb, topic => $oldTopic, params => [ $newWeb, $newTopic, $attachment, $session->i18n->maketext( 'Attachment already exists in new topic') ] ); }


Because this uses the standard rename mechanism, the quickest change (altering this block of code to behave as per Proposal, above) would also alter how normal renames work. This may be unacceptable.

It is not possible to implement this as a plugin because the tests are performed in the user interface, before the plugin hooks are invoked.

If the community deems that changing the standard rename functionality is not acceptable then much of trash attachment must be rewritten. (e.g. This would be the case existing behaviour of attachments moved to another topic where that attachment of that name already exists must fail)

As this behaviour presently exhibits only at the user interface it might be claimed that this will only affect human rather than programmatic access.

Rename Scheme Discussion

This scenario is parallel in many ways to Item23 which had TWiki have issues when the user tried to delete a topic that had already been deleted:

  1. More topic actions | Delete topic... if a topic of the same name as the one you're deleting already exists in the Trash web, you get an "Ad­ministration Error"
  2. i propose to make topics in the Trash web have a unique name (checked when they're moved to the Trash web) (simplest thing is to generate a new name when displaying the oops "delete topic" page (where it says "If this topic already exists in the Trash web you can specify a different name, e.g. TestTopic41234")
  3. Even though topics would then have different names than they originally did, it doesn't matter because of the handy "Put it back" button which will restore the topic to its original web and name
  4. SVN 4364. When there's a clash, it first prepends the originating web name, then if that still conflicts a number is added and incremented until a non-conflicting name is found. So if you delete "AGoodStory" from web "TellMe" and there is an existing "AGoodStory" topic in the trash, first "TellMeAGoodStory" is tried, then "TellMeAGoodStory1" then "TellMeAGoodStory2" etc.
By extension, here's a proposal for the same pattern to be used when a duplicate attachment is deleted:
  1. Make attachments onto the Trash.TrashAttachment page have a unique name (checked when they're moved to the Trash web) , which adds something to make it unique, either:
    1. A number
    2. The name of the user
    3. The timestamp of the delete operation
  2. Even though attachments would then have different names than they originally did, it wouldn't matter if a "Put it back" button could restore the topic to its original web, topic name and attachment name
  3. SVN 4364. When there's a clash, it first prepends the originating web name, then if that still conflicts a number is added and incremented until a non-conflicting name is found. So if you delete "AGoodStory" from web "TellMe" and there is an existing "AGoodStory" topic in the trash, first "TellMeAGoodStory" is tried, then "TellMeAGoodStory1" then "TellMeAGoodStory2" etc. - This makes me wonder why trash for all webs ends up into the same Trash web. Would it make more sense to have a Trash web per web, perhaps as a subweb of that web?

Support for Autorename

  • Autorenaming would be handy indeed, next to the option to custom rename. -- ArthurClemens - 27 Feb 2007
  • This is a usability issue. Yes, auto-rename when needed is a good approach. -- PeterThoeny - 27 Feb 2007
  • Agree, this would be very helpful. -- KeithHelfrich - 28 Feb 2007
  • I fully support this FeatureRequest. * -- MichaelDaum - 27 Feb 2007

Additional features

When undeleting attachments the auto-rename scheme should be transparent enough to guess which one is the right one based on the timestamp and the user name. MichaelDaum - 27 Feb 2007

Should be taken to http://twiki.org/cgi-bin/view/Codev/TWikiFeature04x02 per our current process if someone wants to have this decided.

-- TWiki:Main.KennethLavrsen - 23 Feb 2008

This bug is also reported at Item4514.

-- TWiki:Main.PeterThoeny - 09 Apr 2009

I think the webname prefix is a bit overkill. The "put it back" offers an easy way to undelete. Perhaps change the spec to:

So if you delete "AGoodStory" from web "TellMe" and there is an existing "AGoodStory" topic in the trash, try "AGoodStory1" then "AGoodStory2" etc.

-- TWiki:Main.PeterThoeny - 27 Oct 2009

Above spec is way too complicated. I suggest a simple spec:

Proposed spec: When deleting an attachment and if attachment already exists in Trash.TrashAttachment, do a sequential numbering on file name, such as example.pdf, example2.pdf, example3.pdf, etc.

-- TWiki:Main.PeterThoeny - 2011-01-31

Summary Allow Delete of Duplicate Attachments
ReportedBy TWiki:Main.MartinCleaver
Codebase 5.0.1, 4.2.0, 4.1.2, 4.1.1, 4.1.0, 4.0.5, 4.0.4, 4.0.3, 4.0.2, 4.0.1, 4.0.0
SVN Range TWiki-5.0.0, Wed, 23 Jan 2008, build 16283
AppliesTo Engine
Component Manage
Priority Normal
CurrentState Closed
WaitingFor TWiki:Main.GeorgeTrubisky
Checkins TWikirev:20570 TWikirev:20580 TWikirev:20589
TargetRelease patch
ReleasedIn 5.0.2
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r19 - 2012-12-29 - PeterThoeny
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback