david hunt <dh(_at_)west(_dot_)net> writes:
On Sun, 14 Dec 1997, Alan J. Flavell wrote:
:0 Wh: msgid.lock
| formail -D 8192 msgid.cache
I think you need to make the second line a condition, not an action. Also
Actually, you don't want to do this, as the conditions are tested
*without* the lockfile in place, so that the recipe David included has
formail accessing and modifying the cachefile sans lock. This is not
good. Yes, you can use a global lockfile to avoid this problem by
wrapping the recipe in an assignment to LOCKFILE and the unsetting of
such, but it ain't worth the bother unless you include other
conditions, and even then you could just chain them off the 'standard'
formail -D recipe with the a or e flags. The recipe that Alan gave
above (which is standard one) is correct, it just doesn't appear to be
working for him. Alan, can you provide the complete headers for the
two messages? If you manually feed one of them into the formail
command from the action, does it return failure or success? What OS is
this under, and did you compile procmail with or without optimization?
Can you try recompiling formail without optimization?
the lockfile your using locks a file named "msgid" not msgid.cache. And
you need full pathnames.
It does't matter if it's the 'wrong' lockfile name, as long as
everything accessing the file being locked is using the same 'wrong'
name. Non-full pathnames are relative to whatever your current
directory is -- $HOME until changed by assigning to MAILDIR.
Philip Guenther