The logic for managing attachments is rather confusing.

Updating a file with the same name should not add a new attachment

Example: when I click on the "manage" for attachment "XYZ.zip", it takes me to a page that says "Update attachment XYZ.zip". If I then hit "browse" and select a file that is not named XYZ.zip (say, ZYX.zip) and upload it, it does not update XYZ.zip, instead it adds new attachment ZYX.zip.

Surely if I am on a page with the banner headline "Update attachment" it should do exactly that? Either the banner is wrong, or upload has to be able to rename the uploaded file.

We could do with someone going through all the attachment logic and finding these sorts of problems. I have several clients who have complained about its complexity.

-- CrawfordCurrie - 02 Feb 2004

I've repeatedly had complaints at multiple places about this logic as well.

-- MS - 02 Feb 2004

This was also discussed in UpdateAttachmentsDontWorkAsExpected with no result.

-- AndreUlrich - 02 Feb 2004

TWiki is OpenSource. The CoreTeam will happily accept a solid TWikiPatch following the PatchGuidelines, fixing this flaw

-- PeterThoeny - 03 Feb 2004

Peter, you are of course absolutely right. However, I'll headline to you that this is severely damaging the image of TWiki. Attachments are an important feature, and any complexity or illogic is detected quickly and becomes a major stumbling block, especially for beginners. If a patch is not forthcoming in the very near future, I would suggest you need to be proactive; perhaps actioning a willing volunteer from beyond the CoreTeam would serve.

-- CrawfordCurrie - 03 Feb 2004

Perhaps a mechanism could be added to help with this. A common way many open source projects use is for developers and users to informally "vote" on whether a feature is important or not - using a +1, -1, neutral approach. This is could be termed feature voting. This also helps decouple personalities from the equation as a fringe benefit.

A common way standard software projects use for bugs is to categorise them according to bug severity and bug priority. The former based on technical issues, the latter is almost always based on other factors. There are other ways of course. I would put it that Crawford is arguing for a fix of what is essentially a low severity problem*, but has a high priority.

• * The attachment system works as designed , but confuses users.

Personally the reason I was noting that I've had users mention this in the past was because if we had these systems in place on twiki.org, I would vote +1 for resolving the issue, but vote it as a severity 4 issue (on a scale of 1-5) with a priority of 4 (on a scale of 1-5). No doubt Crawford's and other's opinions would differ.

We don't have those mechanisms, so I thought it worth adding my voice since it would be very nice to see this solved. (But I'm not that fussed at present)

(I'd suggest refactoring this meta discussion elsewhere would make sense)

-- MS - 03 Feb 2004

I don't read from above comments that we need to vote on this. The flaw is obvious. People get confused. We only need a hands-on solution. Anyone outside of the CoreTeam can provide help. But my sense is that it is not trivial, as you can also read in UpdateAttachmentsDontWorkAsExpected.

-- ArthurClemens - 26 Feb 2004

The update attachment table does not list the file size

When updating a file it is useful to compare file sizes.

It seems that in RcsWrap, in sub getRevisionInfo the attachment data is extracted, but I can't find how to get to the size data.

-- ArthurClemens - 26 Feb 2004