Harry Putnam wrote:
I'm probably using the wrong term. I mean the mbox files are only
written to by procmail. But I guess that isn't right either since any
mail client can make changes in the mbox file.
A major reason unlocked mboxes get corrupted is that two procmail
processes try to write to the same mbox at the same time. If you are
using a global lockfile so that every procmail invocation has to spin in
place until the one that has the global lockfile releases it, you don't
need local lockfiles. That's almost always a bad idea, though, because
then two concurrent procmail instantiations that will not end up
modifying the same file can't just go do their jobs without waiting around.
But I'm wondering, Harry, do you have some other setup that keeps two
procmails from running at the same time? For example, are you fetching
mail one message at a time from an upstream host and then running
procmail on your own machine, and doing it in such a way that you don't
download the next message until procmail finishes with the current one?
Then you wouldn't have two procmails running at once, and that's why
you've gotten away with using no local lockfiles.
You're still at risk from what your mail client might do if procmail
pulls a message in at the same time, but maybe you never read while
you're fetching (or never fetch while you're reading).
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail