• 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.

Item5511: Updated attachment gets renamed to attachment name: leads to read errors

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Enhancement Confirmed   n/a  

Edit Form Data

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


If I have an attachment called bbc.pdf and I choose manage and Attach new file, the newly uploaded file gets renamed to bbc.pdf. If this new file is not a pdf file ( txt, whatever) you get strange behavior because the browser and the operating system think it is a pdf file.

-- TWiki:Main/ArthurClemens - 09 Apr 2008

There are use cases for both.

Quick poll during TWiki:Codev/GeorgetownReleaseMeeting2008x04x14:

  • revert to old spec: Arthur, Peter, Markus Ueberall
  • keep this spec change: Martin Cleaver, Colas
  • reject upload:
  • neutral: Kenneth

I feel that we should not change spec on users, too confusing. Also, use case where user wants to rename on upload is a power user feature, less likely used by regular users who are confused if file is renamed on upload.

-- TWiki:Main.PeterThoeny - 14 Apr 2008

Does anyone else want to express their opinion on this bug item?

Do we revert the function back or keep it as it is?

And if reverting is the result who will do it?

-- TWiki:Main.KennethLavrsen - 30 Apr 2008

I believe this change comes about because of the fix for Item5133 and Item5130. You can revert the fix, but if you do so you will have to find another way to fix those problems. The uploading of the attachment to a new name was coming about as a side-effect of an undocumented function call, and appears to have been luck rather than design. There were no unit tests for the behaviour, so when it was lost nobody noticed. It would be better if someone was to actually analyse and unit test the behaviour before rushing into a fix.

On thinking about it my personal view is that the current behaviour is correct, and this report should be rejected; you are managing an existing attachment, not uploading a new one, and the old behaviour was counter-intuitive. The language used in the prompt is "Select a new local file to update attachment", which suggests strongly that you are updating the existing attachment, not uploading a new, differently named, one.

The specific use-case I have seen is where "informal" revision control is used on an attachment that has been debated in email e.g.

  • Alice mails Proposal.doc to Brian, and attaches Proposal.doc to Proposals.Proposal007,
  • Brian modifies it and mails Proposal_brians_rev.doc to Cathy,
  • Cathy modifies it and mails Proposal_brian_cathy.doc back to Alice,
  • Alice wants to update Proposal.doc, and quite reasonably selects "manage attachment" and tries to upload the update - which ends up with a new attachment called "Proposal_brian_cathy.doc" - definitely not what she expected.

I'm pretty sure I have seen support requests complaining about the old behaviour, though I can't put my finger on one right now.

if there is an action on this report, I suggest that from a usability perspective it should be to request confirmation of an update that changes the file type of the uploaded file. It would make sense to check the MIME type as well, though that may be asking too much.

Changed to Confirmed state.

-- CrawfordCurrie - 01 May 2008

After having thought about it also I have come to the same conclusion as Crawford. The current behavior is the most logical. The old was not buggy or wrong. But the new makes more sense to me also. If I manage an existing file I see it as an advantage that I can upload a file with a different name that ends up with the name of the existing attachment.

The kind of file I most often attach is an image file like a png or jpg which is already included and shown in the topic. When I want to update a photo or figure it is annoying that I have have to rename the source file to be the exact same as the existing. Especially when the source file contains some spaces or other special characters. I enjoy being able to just hit manage and upload a replacement which does not get renamed.

So my vote is to reject this report and keep current behavior.

-- TWiki:Main.KennethLavrsen - 01 May 2008

When a new file with the exact filename is attached using the normal way, the old file is replaced. Does this behaviour affect this bug?

IMO, it'd be better if it checks if the filetype is the same, then replace. If not, throw an error. Sure, it's the hard way, but it's the sane way too.

-- TWiki:Main.KwangErnLiew - 02 May 2008

I tend to agree that this functionality is correct. I think that making it verbose and prompting confirmation for a different file type would be ample warning.

-- TWiki:Main.CapHayes - 02 May 2008

Compatible file time sounds very Windows oriented. A file can be of many file types without having a suffix that matches. And unless you make the warning in javascript it would complicate things a lot if a submit transaction becomes a 3 step process. I really want to warn against that. And it is out of question to experiment with something as complex as that for 4.2.1.

We either keep the 4.2.0 behavior or revert. And if we revert we need someone to do it and make new fixes for 5133 and 5130.

I still would like more opinions.

Right now for reverting are: Arthur, Peter, Markus Ueberall And for keeping things as they are: Kenneth, Crawford, Martin Cleaver, Colas. And I interpret Kwang and Cap as for keeping current behavior even though they suggest an advanced error message.

Not a clear majority for keeping spec, but on the other hand if noone steps up to coding the reverted function doing nothing means keeping spec.

-- TWiki:Main.KennethLavrsen - 04 May 2008

I'll go ahead an clarify that I think the current behavior is fine and don't support reverting.

If the extension of the file is different, I feel it should throw a warning, if the file is extension-less, then I believe you are dealing with a user advanced enough to understand what is happening. No one wants to go too far with checking encoding of files and I don't think that is necessary. It should be a much simpler matter to check if they have a mismatch after the dot.

-- TWiki:Main.CapHayes - 06 May 2008

On second thought, the scenario Crawford described above suggests itself. Instead of reverting the old behaviour, the new logic should be kept, documented and, after 4.2.1, maybe supplemented with a file type check ("The replacement for attachment filename1 (mimetype1) is of type mimetype2, are you sure you want to continue?").

Aside from that, a separate "rename attachment" action should be added (also as part of the "move/relocate attachment" dialog) -> new feature request. Once this exists, the semantics of the "update attachment" action should be pretty clear, even w/o the (by then hopefully) existing explanation...

-- TWiki:Main.MarkusUeberall - 12 May 2008

I am for the feature requests that have been articulated:

  1. provide a feedback mechanism to let the user accept/reject the automatic renaming of the just uploaded file
  2. provide the option to rename attachments

-- TWiki:Main.ArthurClemens - 13 May 2008

OK so there is now a consensus as I see it to keep current behavior and instead improve the UI.

I am lowering this to Enhancement as I do not see this enhancement of UI as a release blocker.

-- KennethLavrsen - 28 May 2008

This spec change prompted bug report Item6533.

-- TWiki:Main.PeterThoeny - 2010-07-28

As the author of Item6533, here is my comment on this design decision:

As far as I am concerned I can live with either way as long as the user gets a notification when he:

  • replaces the attachment with one with a different suffix.
  • unintentionally creates a new attachment

I do favour the old mechanism though. I personally think that a user is much more likely to update an attachment from a file with a different name (but same type) than with a file with the same type (but different type). The user expectation that updating an attachment is limiting changes to that attachment only and has no side effect weights strong in my eyes.

Warning the user that he probably changed the file type by checking the suffix on upload also fits well with the suffix change that is done when one uploads '.pl' file for instance. TWiki's interference with the users management of the attachments is then limited to the suffix only.

-- TWiki:Main.StefanWalter - 2010-08-18

Summary Updated attachment gets renamed to attachment name: leads to read errors
ReportedBy TWiki:Main.ArthurClemens

SVN Range TWiki-5.0.0, Thu, 03 Apr 2008, build 16612
AppliesTo Engine

Priority Enhancement
CurrentState Confirmed


TargetRelease n/a

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r16 - 2010-08-18 - StefanWalter
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback