> Alan Stebbens suggested the following to Malcolm Jackson:
>
> | With MH, you must file a message into a folder, and then refile it to
> | the other folders. Here's an example:
> |
> | PATH=$PATH:/usr/local/lib/mh
> |
> | :0:$M/ixin.lock
> | * ^Sender:.*owner-ixion
> | | rcvstore +ixin ; refile last -link -src +ixin +dtp
> |
> | This method is not bullet-proof however. There is a small window of
> | time during which the state of the +ixin folder could change causing the
> | meaning of "last" to not be the most recently arrived message. It is a
> | small window of time, but computers are amazingly fast and quick to make
> | the most of even a small opportunity :^).
>
> Now, I know nothing about MH, so this is an honest (if naive) question:
>
> Would a `w' or `W' flag (so that procmail would hold onto the local
lockfile
> until the shell that runs rcvstore and refile exits) take care of the race
> condition risk? Or what about this so that both MH directories get locks?
The race condition exists between the "rcvstore" command and the
"refile" command on the command line. And, it is not a race condition
between multiple instantiations of procmail; rather, it is a condition
between the human and the computer. While the computer is observing the
locking protocols, the human does not.
Look at the time line below:
t0.. sendmail: receives mail
t1.. sendmail: execs procmail (either as Mprog, or indirectly via .forward)
t2.. procmail: begins reading .procmailrc
t3.. procmail: does ^Sender: match
t4.. procmail: match succeeds..
t5.. procmail: creates lockfile $M/ixin.lock
t6.. procmail: invokes "/bin/sh" on the command
t7.. /bin/sh: invokes "rcvstore +ixin"
t8.. rcvstore: reads STDIN, writes +ixin folder
t9.. rcvstore: returns with status 0 (I hope)
t10. /bin/sh: invokes "refile last -link -src +ixin +dtp"
t11. refile: links "last" message in +ixin to new message in +dtp
t12. refile: returns with status 0
t13. /bin/sh: returns with last status (0)
t14. procmail: recipe succeeds with status 0, processing stops
Probably too much detail, but between t9 and t11 there is a small amount
of time during which a human could invoke a "rmm +inix last" command and
it would not be removing the same message the human probably meant, and,
it would also change the meaning of "last" for the subsequent "refile".
As I said, this is a small nit-picky window of time, and it may never
happen, but the user should know that it *can* happen.
> :0
> * ^Sender:.*owner-ixion
> {
> LOCKFILE=$M/dtp.lock
>
> :0W:$M/ixin.lock
> | rcvstore +ixin ; refile last -link -src +ixin +dtp
>
> LOCKFILE # in case of drop-through on failure
> }
As you must know by now, placing a global lockfile does not solve any
problems in interaction with the human, unless you can force the human
to observe the locking protocol also. This is why I suggested, in my
previous email to use a wrapper script.
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com> http://reality.sgi.com/aks