Jonothan Farr writes:
This is a known bug. Thanks for the patch. The problem with it is that filenames containing backslash characters are valid on Unix. I haven't been able to come up with a solution to this. Any ideas?
That's why I check for a file name that starts with a letter followed by a colon (hmm, maybe should check that it contains at least one backslash as well). While a file name that looks like a full DOS pathname is legal on Unix, I don't remember ever seeing one. IMHO, preventing someone from intentionally uploading a file with a bizarre name like that is less of a problem that making all uploads from Windows machines product bizarre results. Note that this patch only restricts the names of uploaded files. Files that get in the LocalFS directories some other way are untouched. BTW: I'm working on associating other annotation data with LocalFS files. My current thinking is to release the result as a separate product, since I can't think of a way to do it that doesn't hack LocalFS sources. Basically, I'm adding a PersistentMapping (from id to arbitrary class) to LocalFS that can contain one entry for every item in the top level directory with items for lower level directories being PersistentMappings themselves. This seems less of a pain that one mapping with the key being the full relative pathname when the time comes to handle rename, add and delete... The motivation for all of this is an archive of PDF files. I don't want to fill up the ZODB with the PDF files, but am perfectly happy to keep contributor name, short description, etc. there. We'll use a ZClass to store this info, but I don't think that anything but our DTML will need to be aware of the details of it. Comments?