I shall have a think then (and set about doing it) DJB's site has a good explanation on how maildir works http://qmail.plig.org/man/man5/maildir.html
-- Jason > -----Original Message----- > From: Edward Flick [mailto:[EMAIL PROTECTED] > Sent: 04 September 2003 15:24 > To: James Developers List > Subject: RE: IMAP Development Pointers > > > Yeah, maildirs seem pretty effective as a store. Thats > actually what I was hinting at (with a link file instead of > real links as this is a java program and will be running on > platforms which don't support real links). I don't buy into > the idea that creating multiple files will cause much more > disk thrashing, as a spool file can be scattered all of over > the drive too. Although, the open/close efficiency issue is > real, BUT I think this can be counteracted with a good > full-text index file. Also, thanks to the newer journaling > file systems, it would be a lot easier to guarantee that a > message is uncorrupted. Although, I definetely think the > indexing system should be implemented after a simple maildir > implementation is put into place. Anyways, this would just be > a step to at least get this into something close to a beta > phase. What do you guys think? > > -----Original Message----- > From: Jason Webb [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 3:02 AM > To: 'James Developers List' > Subject: RE: IMAP Development Pointers > > > If there is enough interest or need I will write a > maildir-style repository. This is used by qmail and > Courier-IMAP to great effect and provides folders etc., and > it's safe(ish) over networked file systems. The current > repositories are less than ideal other than for folder based > storage ,particularly the mbox one ;) > > -----Original Message----- > From: Jim Wright [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2003 5:40 PM > To: James Developers List > Subject: Re: IMAP Development Pointers > > > Hi Edward, > > I have University of Washington IMAP on my Linux machine > and use an experimental format mx which is as you describe. > To quote the docs: > > . mx This is an experimental format, and may be removed in a future > release. ... > > [snip] > > mx is somewhat inefficient; the entire directory must be read > and each file stat()'d. We found it intolerable for a > moderate sized mailbox (2000 messages) and have more or less > abandoned it. > > [snip] > > > There's a general reason why file/message formats are a bad idea. > Just about every filesystem in existance serializes file > creation and > deletions because these manipulate the free space map. > This turns out > to be an enormous problem when you start > creating/deleting more than a > few messages per second; you spend all your time thrashing in the > filesystem. > > It is also extremely slow to do a text search through a > file/message format mailbox. All of those open()s and > close()s really > add up to major filesystem thrashing. > > I was not completely convinced by this. File system devices > are getting faster for a start. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
