Subject: Re: Using procmail with MH

From: [email-masked] (Stephen R. van den Berg)
Date: Mon, 26 Apr 1993 13:26:29 +0200

""Michelle R. Dick"" <[email-masked]> wrote:
>Filing mail to an MH folder using the action folder/. does not add the
>message to the unseen sequence.  Since I use the unseen sequences
>extensively is it best to pipe the mail to rcvstore instead or is
>there a better way? (and was not updating the unseen sequence an
>intentional oversight in procmail?).

If you want to have those sequences updated, yes, you'll have to use
external programs.  Procmail does not support them directly (and probably
never will, it's too MH-specific).  In your case I'd indeed recommend
using rcvstore.

>Does one use lockfiles with MH and what exactly do they lock?  I have
>lots of incoming mail and also do a lot of refiling while procmail is
>working on incoming mail.  I guess there are three areas that could
>result in problems:

>1. two programs filing to the same folder and when looking for the
>highest number choose the same number (thus one of the messages gets
>clobbered). 

Well, first, you can have any arbitrary number of procmails filing into
the same MH-folder concurrently without any need to use locking, there will
never be a problem (i.e. the messages will not get clobbered and they will
have sequentially consecutive numbers).  This only applies if procmail
does the filing to the MH-folders directly of course.

If you are refiling messages with the MH utilities, there is a very slim
chance  that procmail has already picked a sequence number and the MH utilities
pick the same number.  Causing the two messages to be intertwined, or worse,
causing the procmail-filed message to be lost (because the MH utilities
remove the supposedly non-existent target number first!).

At least this was the case the last time I checked the MH-source.  I haven't
found the time yet to tell the authors of MH to fix their braindamaged number-
selection code.

Of course, the problem only gets worse if you use rcvstore to file messages.
You then have several MH rcvstore instances and one command line MH utility
(i.e. you refiling stuff) working on potentially the same folder.

>2. the mh_sequences file getting garbled (rcvstore updates the unseen
>sequence here).  Slocal screwed this up once.

Yes, this will go wrong eventually.  Rcvstore does not guard against it.

>3. the context file (that holds the current folder name).

I don't think anything touches this file.  Rcvstore doesn't (I think), and
procmail itself doesn't even know it exists.

>Will a global lockfile minimize these problems?  (possibly with
>appropriate redefinition of MH's refile command to use a compatable
>lockfile as well?)

In your case, I recommend using either a global lockfile.  Or (perhaps
better but more cumbersome to retrofit to the MH commands) a locallockfile
per directory.

The locallockfile per directory would ideally constitute a .lock file in the
directory (MH-folder) while it is being updated.  I'm not sure how you would
create aliases (or shell scripts) around the MH commands to make them
support this.

The global lockfile would probably be the most viable solution.

-- 
Sincerely,                                  [email-masked]
           Stephen R. van den Berg (AKA BuGless).    [email-masked]

I've never been superstitious!  Knock on wood.

---

From: Peter Kaminski <[email-masked]>
Date: Mon, 26 Apr 93 08:01:11 -0700

Michelle R. Dick <[email-masked]> writes:
>there a better way?

I use  a _different_ way  (whether it's better  or not is  a matter of
taste...)  -- procmail delivers in  standard fashion  to mailbox files
corresponding to my folders, then I have a set of "inc"  scripts which
make sure the file in question isn't locked, then "inc" from  the file
with the "-file" and "-truncate" switches into the appropriate folder.

I actually don't use unseen sequences currently, but I imagine
everything would be set up properly by "inc".

(I also do some deliveries using the folder/. method, to log and
archive sorts of folders in which I don't manipulate the messages.)

-- 
Pete
[email-masked]