|
This problem still exists in Moodle 1.8.4+.
This also still exists in Moodle 1.9 - it would be great if this can be fixed as the files are basically useless.
The problem can be traced to the fact that the file display function and the unzip function don't use the same "cleaning" method: unzip_clean_filename() has several built in regexs, while file.php calls clean_param (with PARAM_PATH), which has its own more extensive regexs. I've added a patch which changes unzip_clean_filename(); it now also calls clean_param() as part of its cleaning routine.
The desired behavior, then, is to remove strange characters from the get-go, so they'll never cause problems down the road. Thanks for looking into this; I'd meant to look into this and never got around to it. I agree that the desired behavior is for it to strip any special characters, which is what happens when you upload a single file. This bug does render zip upload useless for a goodly number of faculty who end up using some sort of special character in their file name (who are then extremely annoyed at their inability to move/delete a file).
I'll check out the patch ASAP. Thanks Charles,
Really helpful - will try unzip_clean_filenames.diff as well. Deb this is already solved in HEAD
 This solution doesn't work for us. We work with Moodle 1.8.7 with Oracle database and this solution still left some special characters (like ç, ñ, ' ...). Besides, we have solved this problem adding the following lines in the unzip_cleanfilename function (lib/moodlelib.php file):
... It would be possible to revise the code and add this lines to solve definitively the problem? Thank you in advance! Updated per Sara Arjona's comment. clean_filename() is even more restrictive than clean_param(), even when PARAM_FILE is passed (which doesn't make much sense to me).
should be fixed now, please test latest cvs
thanks the report I have tested the latest MOODLE_18_STABLE code from CVS, still getting illegal characters (like space or Czech characters with diacritic marks) in the names of the unzipped files.
which zip method are you using?
reclosing, the internal zipping should work fine too now.
International characters, spaces, etc. are not forbidden, only chars like '"<> are - this is required for backwards compatibility and also they will be allowed in 2.0 thanks a lot for the testing I don't know what exactly is meant by "zip method", sorry. I'm creating the ZIP files using 7-Zip (compression method: deflate, dictionary size: 32 KB, word size: 64).
I think something has got broken by the last fix. I get the following error trying to unzip any ZIP file now: And a final note: If international characters are not forbidden, then why are they removed from the names of files uploaded directly to course files? zip mehods are two, internal using pclzip and external infozib binary,
reopening and sorry for the regression in 1.8.x branch  Thanks for the quick fixes, Petr. Could you please also respond to the question from above: If international characters are not forbidden, then why are they removed from the names of files uploaded directly to course files? Thank you.
They are not forbidden for security reasons. They do break often if you use them. Unfortunately we can not remove them because it would break links in uploaded html files.
In 2.0 all the "not forbidden" chars should finally "sort of" work. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Resolved
Minor
Special characters left in filenames after unzipping
 |
|
I uploaded a simple patch replacing ilegal characters with underscore (on Linux; might be neccessary on other Unixes as well, but I can't test it).
From Jaroslav Šeděnka (jaroslav at sedenka.net) Sunday, 16 October 2005, 03:25 AM:
PS. the code was written by Dan Miksik, I't not like to forget the credits