Tags:
create new tag
, view all tags

Bug: Upload needlessly munges filenames

If you upload a file that has spaces in its name (on a Unix system) the filename is munged by removing the spaces. This seems unnecessary. The illegal characters could be protected by backslash also.

Test case

Environment

TWiki version: Athens
TWiki plugins:  
Server OS: Solaris
Web server: Apache
Perl version:  
Client OS: W2K
Web Browser: IE

-- ThomasWeigert - 28 Aug 2002

Follow up

This is the current spec, problematic characters that are illegal for URLs or file names on various platforms are removed when uploading. This should not matter since you can upload the same file with spaces again and TWiki will do the same filtering again.

Why does that impose a problem for you?

-- PeterThoeny - 01 Sep 2002

I think this is a problem, as somebody can upload two files "aFile.txt" and "a File.txt" and they will end up both as "aFile.txt". This will create a revision, where we actually have two different files. There is no real reason why we couldn't preserve the correct filenames. (See how this is done in MultipleAttachmentsAtOnce.)

-- ThomasWeigert - 02 Sep 2002

Maybe this could also be fixed in TopicSaveErrorWithTopicsContainingSpace.. -- SvenDowideit - 11 Jul 2004

This is a right pain in the backside if you are using WebDAV, which doesn't munge filenames. Create an attachment in MS Word (for example) and try and save it as a filename with spaces to a webfolder. TWiki munges the name, and you (or at least I!) get very, very confused.

  • If WebDAV uses the TWiki upload functionality you do not have this issue -- PeterThoeny - 15 Jul 2004

-- CrawfordCurrie - 12 Jul 2004

Hmmm, this got assigned to me because my patch fixed it already? Otherwise, I will hopefully fix it, if I will have time to. The patch shouldn't be complicated, just adding more $cmdQuote-s to proper places.

-- JurajVariny - 12 Jul 2004

The spec needs to be looked at more carefully, especially for backwards compatibility. Therefore, lets defer this to DakarRelease.

Scenario:

  • With the current spec, if a file called with Space & other Chars.doc gets uploaded, it gets stored as withSpaceotherChars.doc and its URL is %ATTACHURL%/withSpaceotherChars.doc
  • Lets assume we change the spec and implementation to keep filenames "as is"
  • Now lets assume the same file gets uploaded again, it gets stored as with Space & other Chars.doc (some chars might need to be filtered depending on the server OS), and its URL is %ATTACHURL%/with%20Space%20%26%20other%20Chars.doc
  • This is an issue: We have now two files in the attachment table that have the same origin.

-- PeterThoeny - 15 Jul 2004

mmm, i really don't like to keep stuff like this just for backwards compatibility reasons. Could we compromise, by making the default behavoir to not mess with the FileNames, and then supply a setting to make it work like it used to? (i'm wondering if we can't have a BackwardsCompatibility plugin / module)

-- SvenDowideit - 17 Oct 2004

We could work out what the old name would have been, and if that already exists rename it to the uncorrupted name.

-- MartinCleaver - 17 Oct 2004

Fix record

Related problems affecting Cairo are: TopicSaveErrorWithTopicsContainingSpace, UploadMungesFilenames
ChangeProposalForm
TopicClassification FeatureRequest
TopicSummary f you upload a file that has spaces in its name the filename is munged by removing the spaces.
CurrentState ConsensusReached
OutstandingIssues No consensus on whether this needs to be fixed. CoreTeam please set a priority.
RelatedTopics

InterestedParties

ProposedFor

TWikiContributors

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2005-02-15 - SamHasler
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.