Change file uploads so that selecting a file's action and then uploading a different filename will not create a new file.

This has caused a lot of confusion in my company, even though right at the bottom of the action page it clearly says what is going to happen if they change the filename. It goes against the principle of 'least surprise' apparently. They are probably right, so I think this should be fixed.

For example, you upload a file called a.txt. You then click on 'action' for that file, and decide to upload an updated version of that file. Your next version is a2.txt. You upload the file, but instead of it being renamed and updating a.txt, it creates a new file in the file list called a2.txt. Confusing for StupidCorporateUsers.

Implementation Ideas

Proposal 1: When files are getting updated they renamed according to the name of the existing file. No warning message should be displayed as the user wants to update exact this file.

• Problem: The existing file-extension may not match the newer one (png vs. cdr)
• Generally: only rename the part before the dot

If a filetype matcherror occurs display: "Error, File A of Filetype .png cannot replaced by File B of Filetype .gif! Upload File B as new attachment?"

• Yes: Upload the updated file
  • New file gets uploaded as a different attachment.
• No: Go back to View-topic

-- AndreUlrich - 28 Feb 2004

I also think that older files should be accessible. So when uploading a new file, the old file should be renamed. A save way would be to change the part before the dot (assuming the file has a dot), by appending the current revision date (double format, seconds since 1970). So companylogo.png would become companylogo_1077833964.png. The new companylogo.png would get revision 1.2.

-- ArthurClemens - 26 Feb 2004

Uploaded files are stored in RCS, so older revisions are available without fancy renaming as long as you don't change the name of the attachment.

Intuitively I would expect that if I say yes to the question "Update attachment john.dat?" that's exactly what will happen; whatever file I upload will become a new version of john.dat. Even if I upload "jim.gif", I would still expect to be updating the attachment john.dat. Please don't rename the existing attachment! By all means generate a warning ("name/extension don't match - are you sure?") but that's all. I see two approaches, easy and hard, either of which would be fine by me:

Easy

If the name of the uploaded file does not match the name of the attachment, generate a message and refuse to upload it. If that really is the right file, the user can rename it on their local machine and try again.

Hard

If the name of the uploaded file does not match the name of the attachment, prompt for confirmation that the upload should proceed. If the confirmation is positive, rename the uploaded file to the name of the attachment and check it in as normal.

-- CrawfordCurrie - 27 Feb 2004

I don't find it logical to name the newly uploaded file to the old name. I want to try to sketch this in a real world example.

For instance, I have some screenshots of a website in the attachment table. I want to update the schreenshot of the homepage. I really do not care with file format it is in, technically. It is just an image. Let's say I previously attached homepage.jpg, but I find out that someone else should be able to rework the file and because JPGs cannot be reworked without quality loss I decide to go with PNG. I update homepage.jpg to homepage2.png.

Seen from a viewpoint of workflow, not from viewpoint of dead links in the topic text, this is a logical procedure. Now, what next? Most important is to take the user seriously.

1. Of course he wants to update the attachment, so don't bother him with pedantic warning messages (not personal Crawford :). Imagine you need to update 25 files!
2. If the old file is renamed, that is not a big issue. The file is still there for recall. The only thing is that some dead links are created.
3. If the user can take the effort of renaming a file on the local computer, he surely can update the topic text. It would be nice if a list of dead links is generated on the attach page. Not very obtrusive, and not a one-time warning, but something that can stay there for a while to take up the next time.
4. If I update homepage.jpg to homepage.png, and the new file is called now homepage.jpg, the file is useless. Or if remarks.txt has become remarks.pdf.

-- ArthurClemens - 27 Feb 2004

I hear what you say, Arthur, but I don't agree. The problem here is that the name of the attachment is more than just a unique label identifying that attachment. It also identifies the type of the attachment and the associated version stream of the attachment. If you change the label you are clearly not updating an old attachment, but attaching a new, very different, file.

• Do you mean that Rcs can't handle this? -- ArthurClemens - 28 Feb 2004
• No, I'm afraid it can't. Say you start with file XYZ.jpg, and check it into RCS as r1.1. Then you rename the file XYZ.gif, and check in a modified version. Now, if you co -r1.1 XYZ.gif you get the contents of the original XYZ.jpg, but named XYZ.gif. So you have lost the version information that told you what type that attachment was. In most cases, that will leave the revision unreadable. -- CrawfordCurrie - 28 Feb 2004

In your homepage example, that's what you've done; you've removed the jpg type attachment, and attached a new png type attachment in its place.

BTW, if you rename the attachment and there are references to that attachment in the topic text (and possibly other topics) how do you propose to handle them? If you intend to do nothing, then you will be breaking links. If you try to rename the links, you will break content type (e.g. if a user uploads a PDF as an update to a JPG, any >IMG> tag referring to that JPG will henceforth be broken). Don't expect the user to update these links; other people may well have linked to that file without their knowledge.

My interest in this topic is precisely because of confusion among users about how it was supposed to work. The truth is that it doesn't actually matter how it works as long as it is clear to the end user and they are prevented from making obvious mistakes. If you think you can rename the existing attachment and maintain a meaningful version history and type interpretation, and can write testable code to do it, good luck - I think you are biting off more than you can chew, unneccesarily.

-- CrawfordCurrie - 28 Feb 2004

Ok, it seems not possible (with reasonable effort) to keep up a version history which work with different filetypes per attachment. Anyway, if the filetype is not the same, the new file is probably not an update - so let´s get the main request done

I have updated my implementation idea above. In short:

• rename the uploaded file to the existing one which the user wants to update
• when filetypes do not match upload it as a new attachment

Btw, a function to RenamingAttachments would be nice to rename stupid attachmentnames without download and upload them again.

-- AndreUlrich - 28 Feb 2004

I agree with this proposal. I still think that the upload mechanism should be as silent as possible, and we can do without warning messages here.

-- ArthurClemens - 28 Feb 2004

Arthur, that's fine, as long as you annotate the "update attachment" template to describe what will happen, so people don't get caught unawares.

-- CrawfordCurrie - 01 Mar 2004

Bump feature topic marked as scheduled for CairoRelease with 0% SpecProgress

-- SamHasler - 20 Apr 2004

in line with helping CairoRelease finish, I am bumping this feature to DakarRelease. If you want it to go into CairoRelease, please write the code and documentation for it.

-- SvenDowideit - 27 Jun 2004

OK with me to defer this to Dakar.

-- ArthurClemens - 19 Jul 2004

This is, regrettably, a sore hole that still exists in DakarRelease, and is not scheduled to be fixed (Bugs:927)

In practice it does not look too hard to do, if you are any good probably 16 hours would be sufficient. The UI/Upload.pm, attach.tmpl, attachagain.tmpl, Store.pm files need addressing to pass the name of the original attachment down to Store.

Suggestions as to the exact diagnosis would be a valuable first step.

If you want your (or your company's) name on a release as having made a worthy contribution, I suggest you declare your intention to collaborate with us on TWikiIRC. Perhaps we can a couple of companies to fund $100 each towards it?

-- MartinCleaver - 11 Nov 2005

Rod Beckstrom wrote:

> Not sure if this is a bug but you would save millions of mouse clicks by either shutting off this useless warning message that the file name has been changed or by adding a checkbox choice at the bottom to never see the message again. It is the most annoying of regular messages I see in the system and the most useless. It is obvious to a user that the name is changed when they look at the Attachment list.
>
> Can you please remove this simple roadblock?

Related: Bugs:Item443

CC