Robert Hough <rch(_at_)solveinteractive(_dot_)com> writes:
On Sat, Jun 23, 2001, Philip Guenther wrote:
Tell us more about the nature of the folders that this occurs on.
Sorry about that, should have known better. :) I was using mbox mail
folders, over NFS.
Does it only happen on folders that are empty, folders that
contain messages, or does it happen to both empty and non-empty folders?
I would have to vote for folders that contained messages, as I don't
have any that are empty. It appeared to me as if it only happened while
accessing a folder, and new mail came in during the "read" phase.
Um, if new mail came in, then the mailbox *should* be marked as "new"!
I think you need to be still more precise in your description of the
sequence of events that leads to an incorrect 'mailbox has new mail' flag.
Igor Pruchanskiy suggested I try maildir, so I did. So far, I haven't
had any problems with it. Performance is not exactly the best, it will
actually allow much more flexibility in the long run for various things
I've been wanting to do.
"File per message" mailbox formats, while they are more flexible
for scripting than "file per folder" formats, generally have poorer
performance because their primitive operations (creating, stating,
renaming, and unlinking of files) are performed synchronously by the
OS instead of being buffered. Advances in file system technology,
such as soft updates for Berkeley FFS, can mitigate this effect, but
such advances are not widely deployed.
This isn't news to anyone. The "formats.txt" file included with UW's
imap-2000 talks about this, why Cyrus can get away with using a file per
message format (answer: they pre-parse and save the important stuff in
a single file per folder), and why maildir and imap are a bad match.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail