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.
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -