procmail
[Top] [All Lists]

Re: lockfiles

1999-03-01 11:03:53
1999-02-28-01:03:09 Eric Smith:
I cannot work out from the documentation, what is the determining factor of
when to use a lockfile `the final :' and when it is not neccessary.

Well, perhaps it'd be helpful if I explained a little more about what the
"lockfile" support does. When you use that "final :", procmail uses a lock
if-and-when delivering on the recipe. So if I write:

        :0 :
        * ^Subject: testing lockfile stuff
        lockfile-test

then procmail will make a note when it sees the ":0 :" that, should this
recipe be used for a delivery, it'lll need to lock the destination. So when it
sees a message that contains the indicated "Subject:", procmail will make a
special point of locking the mailbox lockfile-test before it delivers into it.
By default it will use a "dotlock" file (lockfile-test.lock), as well as
either fcntl(2) locking, flock(2) locking, or both, depending on what was
found to work when running the configure process while building procmail. In
other words, procmail uses every locking protocol that might work on the local
system. This makes its interaction with other programs good, since as long as
other programs (other delivery agents, and mail user agents) use at least one
of the protocols procmail uses, everything will work Right.

Suppose your delivery recipe was just going to forward to another address:
then there's no need to lock it, since you can have multiple mail delivery
attempts happening at the same time. Suppose your delivery recipe was
delivering into a Maildir-format folder (requires patches with current
procmail releases); then you definitely don't need any locking, since Maildir
was specifically designed to render locking unnecessary.

But if you are delivering into an mbox format folder, it's important, since
two processes writing to an mbox format folder at the same time will generally
corrupt it, lose or scramble one or both of the messages, and maybe even leave
it in a state where the next message delivered into it doesn't get recognized
as a new message, but just gets appended onto the body of one of the broken
messages.

And if you are using the "duplicate-elimination" recipe with "formail -D",
it's very very important to code the recipe something like

        :0 Whc: $HOME/.procmail-msgid.lock
        | formail -D 8192 $HOME/.procmail-msgid.lock

        :0 a:
        duplicates

since you need to guarantee that the message-id database isn't updated by two
formail processes at the same time, then to tell procmail to lock the
duplicates folder before delivering into it (if you're using standard mbox
format).

-Bennett

<Prev in Thread] Current Thread [Next in Thread>