...
> - 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.
Yup - that sounds good.
Only minor downside I can think of at the moment is that if you regenerate an archive after deleting a message from near the start of the mailbox, then the URLs of subsequent attachments will change. I don't consider this a real problem.
...
> 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 :)
If the user sets DIR_PREFIXER to be for example
.../listname/attach/message
then doesn't that mean that we can use DIR_PREFIXER-num whilst retaining
the benefits of DIR_PREFIXER/num (ie we have a fixed directory name with
all of the attachments stored below).
DIR_PREFIXER/num feels slightly neater to me, although DIR_PREFIXER-num would probably be more efficient both in terms of indoes used (as you say) and possibly access time - don't know if it would make any _noticeable_ difference.
Paul Received on Thu 02 Sep 1999 01:32:48 PM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT