Question
While deleting attachments, we are always able to delete the first attachment, but the 2nd attachment always results in an error but the attachment is in fact deleted. For example:
Attachment move failed
During move of attachment
to TrashAttachment an error was found. Please notify your TWiki administrator.
/usr/bin/rcs -o%REVISION|N% %FILENAME|F% of .../Trash/TrashAttachment.txt failed:
Please go back in your browser and try again.
I checked Apache's error log, and see the following error during this process:
[Wed Aug 01 16:12:51 2007] [error] [client 10.1.2.107] File does not exist: /opt/twiki/pub/Main/TWikiPreferences, referer: http://
/twiki/bin/oops/Main/CassandraTargett?template=oopsattention;def=move_err;param1=Trash;param2=TrashAttachment;param3=;param4=/usr/bin/rcs%20%20-o%REVISION%7cN%%20%FILENAME%7cF%%20of%20.../Trash/TrashAttachment.txt%20failed:%20
A couple of additional items:
- I see the 'File does not exist' error for the TWikiPreferences page in nearly every transaction, not just deleting attachments.
- From what I can tell, the definitions for where to put the local preferences file are correct according to the documentation (see attached configure file) so I cannot understand what might be looking for it in the pub directory (which is defined for attachments...see attached configure file).
I am very new to TWiki, having inherited it from my predecessor, so I am not the one who configured the site and may be missing something really obvious. Any help is appreciated.
Environment
-- CassandraTargett - 01 Aug 2007
Answer
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.
It's been about a month without any response and this problem still occurs. We're thinking that it has to do with particular filenames - the ones that have problems are the ones that contain "special characters" such as #@&* etc. I can't find anything about this in any other topic - anyone know if these characters in attachments cause problems? I can see how they would...if so, anyone have suggestions on how to stop users from being able to post such files as attachments?
-- CassandraTargett - 28 Aug 2007
TWiki 4.x should prevent you from attaching files with special chars: It will replace special chars by underscores and will warn users that the filename has been changed on upload. If this is not the case check your configure settings: {UploadFilter} and {NameFilter}
-- PeterThoeny - 29 Aug 2007
I can confirm that TWiki Release 4.1.2 does not do well with an attachment with a pound sign (#) in the name. I was unable to delete it until I renamed the file in the filesystem and edited the wiki topic to refer to the new name.
This file was part of existing content from a previous version of TWiki, thus not caught by an attachment upload name test.
-- PeterNeal - 13 Sep 2007
Stumbling over that question I found a part unrelated to the title, but
still unanswered (the analysis of Peter Neal regarding special
characters in attachments is correct). Quoting Cassandra:
- I see the 'File does not exist' error for the TWikiPreferences page in nearly every transaction, not just deleting attachments.
- From what I can tell, the definitions for where to put the local preferences file are correct according to the documentation (see attached configure file) so I cannot understand what might be looking for it in the pub directory (which is defined for attachments...see attached configure file).
Such an error message will occur if you have a reference to a
non-existing attachment of Main.TWikiPreferences somewhere. Probably
in a template if it occurs on nearly every transaction. Maybe at some
time there has been a CSS stylesheet, or background image, or
Javascript file, attached to the topic which is still referenced?
The attachment directory associated with Main.TWikiPreferences would
indeed be /opt/twiki/pub/Main/TWikiPreferences. Note that there's no
.txt extension, it is a directory if there are attachments.
Since there are so many different ways for a template to point to the
directory, this will be difficult to track down. If you're lucky,
you'll find something like %PUBURL%/Main/TWikiPreferences/, but
it could be %MAINWEB% instead of Main, or
%LOCALSITEPREFS% or whatnot. For debugging you could do the
following:
- Attach some dummy file (any one will do) to Main.TWikiPreferences. This will result in automatic creation of the directory
/opt/twiki/pub/Main/TWikiPreferences.
- Repeat any of the operations which will trigger the error.
- Now have a look in your error log: Apache should now report the exact file name TWiki is looking for.
- grep for that file name, first in your
templates directory, then in lib/LocalSite.cfg, then in the data directory, and find out why it is there.
- After fixing this, you can remove your dummy file. Unless it contains a
#, of course ;->
-- HaraldJoerg - 14 Sep 2007
Peter - Thanks a lot for the hint about checking the NameFilter and UploadFilter. People are still complaining about this problem, and it appears these are attachments uploaded AFTER our upgrade to 4.1.2 in June.
Here are our values for UploadFilter:
^(\.htaccess|.*\.(?i)(?:php[0-9s]?(\..*)?|[sp]htm[l]?(\..*)?|pl|py|cgi))$
NameFilter:
[\s\*?~^\$@%`"'&;|<>\x00-\x1f]
Peter, was your point to say that I should add # to these values?
Thanks also Harald for the tips on finding that error - I'll give it a shot.
-- CassandraTargett - 16 Oct 2007
Sorry, closing this after more than 30 days of inactivity. Please feel free to re-open if needed.
-- PeterThoeny - 03 Dec 2007
this problem was still never resolved:
While deleting attachments, we are always able to delete the first attachment, but the 2nd attachment always results in an error but the attachment is in fact deleted
-- AndrewKim - 2012-05-30
Ah, special case when {UseLocale} is in use. That is why I first could not verify it. If not, the # is already filtered. This is tracked (and now fixed) in TWikibug:Item6888
.
Fix in TWiki.spec:
$TWiki::cfg{NameFilter} = qr/[\s\*?~^\$\#@%`"'&;|<>\[\]\+\x00-\x1f]/;
-- PeterThoeny - 2012-06-18