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