At 12:48 PM 11/21/00 -0600, David W. Tamkin wrote:
Andreas Tindlund had this recipe,
T> :0:
T> * ^FROM_DAEMON
T> $DEFAULT
And Michael Keating's response included this, which is very much incorrect:
K> [No lockfile needed there. Second colon can be omitted.]
I meant to say (wrongly, in this case) that procmail will automatically
generate a lockfile. See below.
Michael's advice there may be not merely wrong but outright destructive.
$DEFAULT likely points to a plain mbox, and that second colon for a local
lockfile is very seriously needed. If $DEFAULT points to a directory, then
no, it isn't, but the snippet of logfile Andreas showed us implied that his
$DEFAULT is a plain folder.
Thanks for catching that. Reading the original log, I see that the message
was not delivered to the system mailbox. The original recipe, as quoted,
did not set $DEFAULT to a new value, and I did not look at the delivery
section of the logs. If $DEFAULT equals /var/spool/mail/$LOGNAME and
procmail is delivering to $DEFAULT, then procmail will automatically
generate a lockfile. To any other file, the second colon is certainly
essential.
If we had no way to know whether it was a directory or a plain folder, it is
far safer to err on the side of caution. A local lockfile for a save to a
directory wastes a few CPU cycles but does no other harm; lacking one for a
save to a plain folder can result in intermixed or lost messages.
Agreed. Caution is best. In the case where delivery is to
/var/spool/mail/$LOGNAME, the colon is no waste of CPU cycles. To any other
file, the colon is crucial. To a directory, it is inexpensive.
--
Michael
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail