Date: Sat, 21 Feb 1998 11:47:16 -0800
From: Bill Wohler <wohler(_at_)newt(_dot_)com>
Message-ID: <199802211947(_dot_)LAA01620(_at_)gbr(_dot_)newt(_dot_)com>
| When Richard
| finishes the nmh file locking though, using rcvstore will be good to
| prevent any possible problems due to unlocked maildrops,
Yes - though in practice the main problem with locking with MH folders
is with updates to the shared files (.mh_sequences, etc), rather than
with updates to the directories themselves ("link(2)" generally works OK
to prevent two files getting renamed into the same thing - and procmail
does use link, and retry with a higher number if the link fails). If
sequences aren't being updated, whatever locking rcvstore might do (which
will be a good thing when it happens) isn't likely to matter all that much.
The one time it might would be if you have multiple (different) systems
attempting to link into the same folder in an NFS mounted maildrop - as
link isn't guaranteed over NFS with competing clients (though it doesn't
often fail even there), in that case a locking mechanism that works over
NFS is going to be needed to solve it (which really means using lockd,
nothing using NFS primitives can work for certain).
| - for the one who thought that procmail read ~/.mh_profile: I doubt
| that it does. You probably have MAILDIR set to your MH directory.
Ah yes, you're right, and apologies to all, I do have MAILDIR set (in
procmailrc for anyone who missed the reference) and that's how it works.
In any case, having a non-standard mh Path doesn't result in procmail
putting messages in weird places - procmail can at least be told how to
cope, the pointer to its MAILDIR (which I am sure must be documented, as
I had it set, and I'm certainly no procmail expert) is useful.
kre