example:
- I have a file.txt which I upload as an attachment, it is 10kb.
- manage file.txt shows one version, with size 10kb
- I add data to my copy of file.txt, it is now 20kb. I update the attachment by uploading it as the same name.
- manage file.txt shows two versions, BOTH showing a size of 20kb
- Add 10 more kb of data to file.txt, upload and
- manage file.txt shows all three versions as being 30kb.
This also happens if you decrease the attachments in size- if you start with a 30kb file, and your latest update is 10kb, all show 10kb.
Attachment version history should display the size of the file 'as was.'
This happens both on my local copy of TWiki and when I tested it in the twiki.org sanbox.
Yes. Hmmm. Nasty.
CC
With 4.0.3 out the door I think it is safe to raise this to requirement.
--
SP
Are you
sure?. Attachment size histories are not recorded anywhere, so to determine historical sizes of attachments would require checking out each old version in turn and finding the file size. This would be very inefficient, as well as complex to code. Is it
really that important? Or might it be better to simply
not try to report the size of old revs of attachments?
CC
Both would work for me.
I never noticed this as a performance issue in Cairo, but if it is complex to re-insert the feature in Dakar now (I presume it would be the new storage backend that is making this troublesome now?), let's give it a second thought. Perhaps a place to apply some AJAX later on, if we choose to silence the sizes out for now.
--
SP
FYI Cairo didn't get it right either.
CC
Yeah, I see it, sizes are not mentioned in the skins in Cairo for earlier revisions. I think looking at the Cairo code got me distracted, looked like some preparations were done.
Setting this normal.
--
SP
I can also easily live with not seeing sizes in the history view of attachments.
It is not essential at all. It is nice to see the current size but the history of sizes is a nice to have and it is not at all important. I'd rather have slimmer code than adding this feature.
--
KJL
With that level of agreement, i think we can safely drop this to Low.
CC
I would like to bump this back to normal - with the agreement that the FIX for this is to remove the size of earlier versions of attachments from the
PatternSkin.
So I bump this to normal and change the headline so it matches the agreement above.
I have seen more people mention it on #twiki so it is an annoying little thing.
If some still wish to see the sizes reported on earlier attachment versions they should open an additional bug item marked as enhancement.
KJL
Removed size column from version table (not attachment table), SVN 12188. Please open a new request if you feel like the size should be in the version table.
--
PTh
4.1.0 released
KJL