LuKreme [mailto:kremels(_at_)kreme(_dot_)com] wrote:
On Tuesday, Jan 7, 2003, at 03:10 Canada/Mountain,
dman(_at_)nomotek(_dot_)com
wrote:
:0 Wh: msgid.lock
| formail -D 16384 msgid.cache
I'd say that it's because the W flag told procmail the thing didn't
work, so it sent back a "delivery unavailable" code to procmail.
Note that the lockfile is going to protect the duplicates file
you save to; but that the formail cache is *not* protected by
a lock, and does involve a potentially destructive write operation.
Ah. That actually makes sense, sorta.
Uh, no, it doesn't. I misspoke. I wrote that pretty fast, and
I was thinking of my dupes checker but not really looking hard at
yours.
There are two forms of dupe-check recipes in procmailex. You use
the first, but I use a variation on the second. Form 1's theory is
that the delivery succeeds when the message is a dupe --> /dev/null.
For non-dupes, formail -D fails, but the W flag ignores the failure,
so delivery didn't happen and procmail continues with the rc.
msgid.lock does protect the pipe here.
At least that's the way it looks to me now, on reflection.
IOW, I have no idea why you lost 61 fetchmail messages.
I use a regional lockfile on my dupes snagger for this reason.
Could you provide more detail on said "regional lockfile"
Look that up in the list archives; and see "LOCKFILE [global]"
in man procmailrc.
Here's my dupe checker, though:
LOCKFILE = msgid.cache.lock
:0 # 030106 () weed out duplicate mail
* ! TEST ?? ^^(y|on)
* ! ^X-BeenThere:
* ? formail -D 8192 msgid.cache
duplicates
LOCKFILE
Hey, baby, I've got just the cure for that penis envy back at my
apartment...
Puh-leeze. Can we cut it out with the sophomoric unfunny sex
jokes?
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail