> From: Philip Guenther <[EMAIL PROTECTED]>
> Date: Mon, 01 Feb 1999 18:45:14 -0600
>
> 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.
I was getting bitten by it a *lot* because by using qmail with lots of
different mailboxes, I've got a lot of parallelism in my email. I wrote a
wrapper for rcvstore that looks like this:
#!/bin/sh
PATH=/usr/local/nmh/lib:$PATH
export PATH
lockfile $HOME/Mail/$1/.lock
# Only mark message unseen if the message is not from me.
# For this to work, .mh_profile must *not* specify an unseen-sequence.
if [ "$SENDER" = "$USER@$HOST" ]; then
echo "me"
rcvstore +$1 -nounseen
else
echo "notme"
rcvstore +$1 -unseen
fi
rm -f $HOME/Mail/$1/.lock
lockfile being the only part of procmail I actually use any more...and, yes
there is a risk of contention with other nmh functions, but since I don't use
inc, there's not a lot of chance of something else updating the sequence at
the same time and I haven't been aware of being bitten by the problem.
When nmh gets locking integrated, I hope it'll be done in a compatible fashion
with procmail uses.
Chris
--
Chris Garrigues Deep Eddy Internet Consulting
+1 512 432 4046 609 Deep Eddy Avenue O-
http://www.DeepEddy.Com/~cwg/ Austin, TX 78703-4513
My email address is an experiment in SPAM elimination. For an
explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
Nobody ever got fired for buying Microsoft,
but they could get fired for relying on Microsoft.
PGP signature
