Hal DeVore <[EMAIL PROTECTED]> writes:
>In message <>, Richard Coleman wrote:
>>I've been using procmail and rcvstore together for a long time
>
>Me three. ...
Okay, let me say this again. If multiple processes access and update a
file without locking, then a race condition exists and changes may be
lost or the file may be corrupted. Period. You may be lucky, but that
doesn't mean you're safe. For those of you who say that you've never
seen this happen, are you really sure it hasn't: has a message ever
mysteriously not been added to the unseen sequence?
Now that we've established that a risk exists we can ask the question,
how big is it? For many people, the risk is small enough and the cost
if it occurs is bearable. For others, perhaps those who receive mail
more often (thereby increasing the risk) or those who use a lot of
sequences (thereby increasing the cost on failure), it is not a good
choice.
What I'm trying to say is that the mailing list should not blindly
recommend using rcvstore in asynchronous situations without making the
user aware of the risks, because they are the only one who can make the
call as to whether the risk and cost is worth the benefit. Even just
pointing the user to the BUGS section of the rcvstore(1) manpage would
be enough.
>... And the minimalist .procmailrc I posted earlier today shows how
>to use procmail locking and rcvstore.
That locks against multiple procmail invoking multiple rcvstore
commands simultaneously, not against an rcvstore and an 'inc' or a
'show'. As the current primary maintainer of procmail (Stephen's been
too busy, so he dubbed me) I've updated the procmailex(5) manpage to
mention that the example it contains is not proof against corruption.
Philip Guenther
----------------------------------------------------------------
Philip Guenther UNIX Systems and Network Administrator
Internet: [EMAIL PROTECTED] Voicenet: (507) 933-7596
Gustavus Adolphus College St. Peter, MN 56082-1498
