Question

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?

Environment

-- MichelleAlbertin - 14 Mar 2008

Answer

If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list 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

Sean,

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