• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

An old problem is back after the hotfix 3 (probably from the security update for attachments).

When you attach a file to a topic with Internet Explorer the entire original path becomes the filename.

In Firefox it is only the actual filename.

This makes TWiki impossible to attach files to in a corporation where IE is the standard browser. And that is probably 99% of all corporations.

This is the 3rd time now we have this issue in TWiki. Each time it is fixed and then someone puts back the old error again.

And we need a test case so we do not see this again.

I have spent hours today trying to find the many topics that have beed screwed up by this bug. I fear quite many have this issue right now after applying hotfix 3. So we need a FIX asap for a hotfix 4.

The last bugs item was Item2225

KJL

I know the root cause of this issue.

And I have implemented a fix.

I will test it a little more and check it in later tonight

KJL

I got this report by e-mail:

Bug in TWiki 4_0_4 with hotfix 4_0_4_3

I just wanted to report a bug, but the registration form did not work on twiki.org.

The bug regards the following lines in TWiki:UI:Upload.pm:

185    my $origName = $fileName;
186
187    unless( $doPropsOnly ) {
188        ( $fileName, $origName ) =
189          TWiki::Sandbox::sanitizeAttachmentName( $filePath );

Line 189 should look like this:

189          TWiki::Sandbox::sanitizeAttachmentName( $fileName );

This bug was introduced by one of the hotfixes, because in the 4_0_4 release everything worked well.

Yes, to new hotfix 4, and yes on test case.

-- PTh

I have now tested a lot. And it is good you also had this additional fix. I had only fixed some code in Sandbox.pm

The issue is that File::Spec functions like split are works differently depending on the HOST. Under Unix it assumed / for paths and under Windows it assumed \. But in Sandbox.pm function sanitizeAttachmentName it is used to split the path name given by the browser. So you will see C:\blabla\filename type paths which the UNIX version sees as one filename and does not split at all. So these functions cannot be used to handle path names from the client.

So I used the old split code that was removed which seemed to work fine anyway.

I have been testing the fix for a while now and it actually also seems to fix something else. It seems that for a long time all files uploaded were marked as autoattached.

I have no chance of writing a testcase which emulates both the way IE uploads and FF uploads files. That I will have to leave to others. I added a comment in Sandbox.pm which hopefully makes others check carefully before changing this code again using File::Spec or similar.

But the bug seems fixed and ready for a hotfix4. Let is test another day before we release it.

I will check in the two files that changes now.

KJL

ItemTemplate
Summary Attachments are being named the full path name instead of the filename only AGAIN (introduced by Hotfix 3)
ReportedBy TWiki:Main.KennethLavrsen
Codebase ~twiki4
SVN Range TWiki-4.1, Tue, 12 Sep 2006, build 11476
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 11482
TargetRelease patch
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r7 - 2006-11-14 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback