On Mon, Aug 04, 2003 at 09:48:55PM +0200, Lukas Beeler wrote: > * Peter Stuge <[EMAIL PROTECTED]>: > > Apparently nobody cares what DJB writes, which is really too bad, since > > I think he is a very good author. > > I do care,
Actually I was mostly referring to procmail and whatever other IMAP server I tried that had appended ,S=nnnn to the delivery identifier when moving the message to my cur/. > but i was in a real hurry when composing my mails, > thus leading to my mistakes. Ah, yes. Been there. :) > I've reread the spec now. > > I apologize for any inconvenience caused by me. You didn't cause me any, and I don't think anyone else either. Like I said, I think this is an interesting issue. On Tue, Aug 05, 2003 at 08:39:25AM +0200, Andreas Aardal Hanssen wrote: > On Mon, 4 Aug 2003, Peter Stuge wrote: > >I have always considered this an interesting issue and will now rant and > >express my opinion at large for a couple of screens. Scroll down if you are > >easily offended. ;) > > I'd like to add something.. > > If the format of the filename is not what DjB suggests, how can one > guarantee filename uniqueness? How is one guaranteed that a message in > new/ will not have the same unique name as one that is in cur (or will > show up there in a microsecond)? You mean tempnam() isn't good for creating globally unique filenames? ;) > I'm willing to accept this as part of the spec, but Binc IMAP and > Courier-IMAP's practise today of using the filename to deterimine the > internaldate (which of course is _very_ fast compared to a stat) Doesn't this depend largely on which filesystem is used? > isn't > reliable when a filename can have any format (and information should not > be extracted etc). > > With a 20k mailbox, stat'ing all files is extremely slow compared, Patient: "Doctor, please help, it hurts when I have huge mailboxes." Doctor: "So don't have huge mailboxes." Another option might be the use of imon/fam technology, where userspace applications can subscribe to files (and directories?) via system calls, and get notification when things change. This way the imapd would cache metadata from slow filesystems in RAM to increase performance, and only have to reread from disk when things change. > not to > mention the race conditions introduced with readdir, then stat (oops, > ENOENT). I'm frankly not quite sure how to deal with this. If a file suddenly disappears, there's nothing to do about it. It's gone. Just tell the user, maybe by removing it from the internal list of files/messages. > Andy - any ideas for a new mailbox format? I honestly think maildir is good enough. I'm willing to take a performance hit for reliability, I do however agree ext2 may not be the best filesystem to handle huge maildirs. Have people tested different filesystems for this specific usage? Maybe it's a new filesystem we need? I don't know, but am curious. //Peter
