On Wednesday, 17th June 1998, Richard Coleman wrote:
Ever since I switched from plain 'inc' to a complex procmail and rcvstore
mail delivery mechanism, I have been plagued with disappearing sequences.
I have traced this to optimistic handling of context and .mh_sequences
files in nmh.
MH is very haphazard about the way it manipulates folders. Every
command open and closes the files itself. There are lots of race
conditions in MH, if commands are used in parallel.
Yes, if run strictly in sequence there would be no problems. But that's
not how it is with automatic mail delivery.
Part of the reason for the current restructuring of nmh, is to change
the internals so that folder manipulation always uses a standard
library interface. I've been slowly working on this in nmh. Several
nmh commands (rcvstore, refile, and soon mhn -store) use the library
interface folder_addmsg() to add messages to a folder. Once this is
completed, it will make it possible to add a robust locking scheme.
This is the way to go, but until then, the changes I made are useful.
By the way, when you switch to folder_addmsg() throughout, remind me
to press for a change to the mechanism for selecting new message
numbers. I want new messages to be after cur, even if the cur message
has been delete.
Also, you mention you are using a procmail/rcvstore combination.
Make sure you use procmail locking on the folders. I've been doing
this for years, and have never noticed a problem.
Running without locking was suicide. I got that right some time ago.
Here is a snip from my .procmailrc:
:0 w :auscert/.lock
* ^From auscert
| rcvstore +auscert
Even with this most sedate procmail delivery mode, I lost my sequences
frequently. Obviously the mail delivery programs overlapped with mail
reading and deleting, but I also occasionally read more mail while a
slow pick ran in another window. Since I added my patches, I have had
no problems, even with large sequences. In theory, my unseen sequence
should be plus or minus one message occasionally (about as often as I
lost it completely before), but in practice this appears not to be a
problem.
Stephen.