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

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