From: jose.kahan@w3.org
Date: Wed Sep 01 1999 - 12:00:47 CDT
Hello,
Following from last month's discussion about storing MIME attachments
in a separate directory, I give here a summary of the concerns, give
a little critic of the present solution, and defend again my alternative
approach (already tested :-).
Please give some feedback to the list for/against implementing the alternative
in the hypermail base.
The main concerns were:
1 Storing the attachments in a separate dir, e.g., for being able to
mount them eventually in another volume
2 What filename to use
2.1 avoiding funny user names, such as .htaccess.
2.2 being able to reproduce the archive from scratch and not break any links.
2.3 avoid having one attachment overwrite an existing one.
2.4 what to do if an attachment doesn't have any name
2.5 avoiding having the user download an attachment he doesn't want to
see (e.g., a word macro virus...)
Another problem is how to store the content type. I have a proposition that
I'll mail in a separate message to the list.
The implemented solutions is:
- attachmentlink option to specify the format of the attachment link
--> this solves point 2.5
- attachments stored under DIR_PREFIXER/num/FILE_PREFIXER-attachname
where DIR_PREFIXER and FILE_PREFIXER are the chain "att-". There is a
simple protecting against having two identical attachnames, but it may create
some temporary names (thus a risk of breaking links). If there's no
attachment name, a temporary one is created.
This solves points 2.1, and 2.3, and, IMO, partially solves 2.2 (tempname
risk), solves 2.4 (but breaks 2.2, tempname risk again).
So the main problem here is point 2.2
=======================
My alternative solution is quite close to the present one and solves point
2.2:
- Store attachments under DIR_PREFIXER/num/attachnum-attachname,
where attachnum is a counter which gets incremented for each attachment
in a message (and reset for the next message).
- Use the filename attachnum-part for nameless attachments
As I'm using an "attachnum-" prefix, this covers points 2.1 and 2.3, The
-part suffix covers for point 2.4. Finally, as I'm always able to
reproduce the same filenames, I cover point 2.2.
Does this make sense to you?
I have some little extra work to, so that attachnum gets incremented even
if the maintainer forbids the storing of a specific type of attachment. It'll
then be possible to allow the new type later on without breaking links.
================
Related open question (n.b, I don't remember if we can change DIR_PREFIXER
thru the options, but the code seems to say no):
Should we use DIR_PREFIXER/num or just DIR_PREFIXER-num?
It makes sense to use DIR_PREFIXER/ if we can move the attachment directory
to another volume and mount it there, without breaking links (should
be thought in advance). Otherwise, we can save n x months inode and n times
one char ('/'), by using DIR_PREFIXER-num.
A more customizable option would be to be able to choose the directory
(none, DIR_PREFIXER, another path), and the -num prefixer (DIR_PREFIXER,
nothing). Then everyone can configure hypermail as he wants :)
I'm waiting for your feedback :)
Thanks,
-Jose