create new tag
, view all tags


Came across an odd attachment problem ..

When I upload a new attachment version via the 'manage' link, with same name as old attachment, the old version is opened when using the below attachment link in topic source. The new version is opened when opening attachment directly from the attachment table.

Following syntax is used to provide access to org chart within the topic's text:

 [[%ATTACHURL%/orgchart_2008.ppt][<b>Open Org Chart</b>]] 

The only way I've found to prevent this is to change the attachment name on upload of new version. Is this a known problem or even expected behaviour? Any work-around?


TWiki version: TWikiRelease04x01x02
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: Solaris 10
Web server: Apache 2
Perl version: 5.8.4
Client OS: Windows XP SP2
Web Browser: FF & IE

-- MichelleAlbertin - 14 Mar 2008


ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

This most likely a browser caching issue. Do a Shift-reload on the attachment.

You could also specify a link that reloads the attachment: [[%SCRIPTURL{viewfile}%/%WEB%/%TOPIC%?filename=orgchart_2008.ppt;rev=3][Org chart]] (assuming rev 3 is the latest attachment version)

-- PeterThoeny - 14 Mar 2008

To eliminate browser cache issues, I've cleared cache, restarted browsers and had colleagues who have never open the doc, open via both links. All leads to same problem. Our sysadmin is looking at possible server-side cache issues. Meanwhile, here is a bit more info...

Viewing source, I see the attachment table link looks like this:

<a href="/twiki/bin/attach/Webname/TopicName?filename=orgchart_2008.ppt&amp;revInfo=1" title='change, update, previous revisions, move, delete...'rel='nofollow'>manage</a>

The embedded link created through attachment properties:

<a href="http://OurURL/twiki/pub/WebName/TopicName/orgchart_2008.ppt" target="_top"><b>Open Org Chart</b></a>

We are using the 'Create a link to attachment' attachment property as the standard method for embedding attachment links in topics across our web. This generates the %ATTACHURL% link mentioned above. We are also constanly updating versions on most of these attachments, so specifying rev. no. in link is not really an optin. Any other ideas as to why this may not be working?

-- MichelleAlbertin - 17 Mar 2008

Sorry, closing this question after more than 30 days of inactivity. Feel free to re-open if needed.

-- PeterThoeny - 01 May 2008

Hi Peter,

I'm encountering a similar problem to Michelle's. When users upload a new version of an attachment, it often doesn't display the latest version when clicking on ANY link to the attachment (whether in the topic or the attachments table), except for the one under Version History on the Update Attachment screen.

For me personally, this occurs only in IE and not in Firefox, which is strange because my cache settings look pretty much the same in both browsers. What's worse though is that doing a hard refresh in IE (v. 7) doesn't even solve the problem. I've tried a couple times and had to go in and delete all my temporary internet files in order to see the latest version.

I understand that, functionally speaking, this is a browser issue, but it also seems like a design failing of TWiki since the same caching issue doesn't occur for my users when making updates to actual page content. What is the difference in the way the attachments are served versus the way the topic text is served? Are there any changes that can be made to TWiki's config settings or to any of the View scripts that would force the browser to serve the latest version of the attachment?

Thanks so much for your time.

-- GarySprague - 24 Jul 2008

> the same caching issue doesn't occur for my users when making updates to actual page

You have probably noticed that the edit link uses a dummy time variable. That ensures that the requested URL is unique and therefore not cached.

You could do the same thing with image links, like so: <img src="%ATTACHURLPATH%/sample.gif?t=%SERVERTIME%">

It would take some digging in the code to figure out how to generate those links with the parameter, and you might use GlobalReplacePlugin to fix the links that users have already created.

-- SeanCMorgan - 07 Aug 2008

I am having the same issue Gary described. I am using IE 6.

  1. Upload a file from my local PC. Result: Everything works great.
  2. Update that same file on my local PC keeping the same file name. Upload this file again (version2) using the same name. Result: Clicking on the attachment name in the topic still shows version 1. The only way to see version 2 is to click on manage and then click the view link for version 2 in the version history table.
  3. Try uploading version two with a different file name. Result: Same problem as 2.

-- MichaelCarter - 08 Aug 2008


Most of our attachments are not linked directly in the topic text, just in the Attachments table. I'll hunt around to try and find out how the links in the table are generated, and see if I can apply the same kind of fix with the time parameter that you suggested.

I had also seen a suggestion on another similar support question to use a viewfile script that had been deprecated at some point...and then there was another caching issue that was solved by changing the ExpireDefault directive in Apache...All in all I'm just not sure where exactly the problem begins and ends between the TWiki files, the webserver, and the end user's browser.

-- GarySprague - 11 Aug 2008

On 2nd thought, you shouldn't have to add that time parameter (though it would work), because, as you pointed out, the text content doesn't require that when in view mode. It's added to the edit commands only.

The Apache directives are probably not at fault, since the text content cache is working properly.

Given that you only see it in IE and not Firefox, I'd search Microsoft's KB to see if it treats MIME types differently with respect to caching.

-- SeanCMorgan - 11 Aug 2008

Thanks, Sean. I think you're right about the Apache directives. I set the ExpireDefault directive to "access" and there was no difference in the behavior. I'll check the Microsoft KB and see what I can find.

-- GarySprague - 12 Aug 2008

Closing after more than 30 days. Please reopen with more details if needed...

-- PeterThoeny - 06 Nov 2008

Was there ever any follow up on this? I've been scouring the support pages and not finding anything. Is this truly working as intended for some people?

I'm running TWiki-4.2.4, Sat, 06 Dec 2008, build 17773 on Apache. On Firefox or IE, when I click on a document link, I get the first version. That's for both an embedded link and a link in the attachment table. The only way to get the latest version seems to be to manage the document and click on the latest revision. Even on the manage page, the link in the table goes to the oldest version.

Interestingly, it seems this might be linked to file type? I reproduce this consistently with Office 2007 files, which happens to be what we share the most. I just tried a text file, though, and got the intended behavior.


I'm trying to build a wiki culture but this is really setting me back so any help would be incredibly appreciated!

-- HeleneMartin - 16 Jan 2009

You could modify the attachment link to append a timestamp parameter so that you get a unique attachment URL each time you look at a page. Append parameter ?t=%SERVERTIME{$epoch}% to the URL which gets expanded to ?t=1232075173. See ModifyLinkFormatInAttachmentTable.

-- PeterThoeny - 16 Jan 2009

You can find another solution here: ModifyLinkFormatInAttachmentTable. It uses the viewfile script to serve attachments, which adds filename and revision parameters to the URL to ensure you always get the latest version. Apparently, according to the conversation on the linked page, it also adds security to attachments, ensuring the person requesting them has access rights to view them. The only downside versus the default attachments setup is a loss of speed, but to be honest I haven't noticed that. Maybe if I had really hefty attachments or people were uploading and modifying attachments all the time it would be more obvious.

-- GarySprague - 16 Jan 2009

FYI, I meant to point out that neither of the two above solutions, mine or Peter's, will help you with embedded attachments links, ie those contained in the body of the topic. Those links will still experience the caching issue, at least in certain browsers. I've recommended to all of my users not to place attachment links within the topic text, but just to reference files contained in the Attachments table.

-- GarySprague - 16 Jan 2009

Thank you both for your quick responses Gary and Peter. Not quite as satisfying as I might have hoped but very helpful.

I'm still puzzled by the file type issue. As I mentioned, *.txt files get the intended behavior. *.jpg files as well. Why not *.xlsx? It seems like it has to be a server-side issue, no?

-- HeleneMartin - 16 Jan 2009

Possibly a mime type issue? Check your twiki/data/mime.types file.

-- PeterThoeny - 16 Jan 2009

I came across that same problem with Office 2007 file attachments, but in my case it wasn't even serving them correctly. When you tried to open them in Excel, it would tell you the file was corrupt or possibly missing data. I submitted a support request and got an answer that allowed me to resolve the issue: Excel2007AttachmentsProblem. In addition to adding the Office 2007 types to the mime.types file, I had to make a slight edit to the View.pm file. Both of those are detailed in the linked support request. Good luck!

-- GarySprague - 17 Jan 2009

Change status to:
Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2009-01-18 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.