valdis.kletni...@vt.edu writes:
On Sat, 16 Feb 2013 15:30:55 -0700, Joel Uckelman said:
The second colon tells procmail to use a lockfile for this recipe, and
the path after that is the lockfile name. Messages can come in any
time; the lockfile ensures that two runs of rcvstore don't step on
Has anyone ever experienced this theoretical corruption? I haven't. I
use procmail's locking, but then other nmh programs don't use that same
locking mechanism.
So it depends what you mean by procmail's locking. If you're using
locking in procmail so only one rcvstore is running at once, then
Ken Hornstein writes:
What it doesn't mention is that the resulting train wreck can mangle other
sequences in the .mh_seq file as well. Also, should we change that text
to say do not use rcvstore without an external locking mechanism'? It's
perfectly save to use it from procmail with unseen
So are you saying that I don't need to specify locking in my procmail
recipes any more?
Sadly ... David is right in that you still do need to do that. The sequence
file won't get corrupted anymore, but we'd need to lock the whole file during
message receive to make it work right. It occurs to
On Sat, 16 Feb 2013 15:30:55 -0700, Joel Uckelman said:
The second colon tells procmail to use a lockfile for this recipe, and
the path after that is the lockfile name. Messages can come in any
time; the lockfile ensures that two runs of rcvstore don't step on each
other's toes.
And the
Valdis wrote:
And the exact gotcha involved, from 'nman rcvstore':
BUGS
If you use the Unseen-Sequence profile entry, rcvstore
could try to update the context while another nmh process is
also trying to do so. This can cause the context to become
corrupted.
I removed that notice from the man page after 1.5 went out.
However, I shouldn't have. Ken added locking to the context
and sequences files nearly a decade ago. That addresses
file mangling during write, but not possible interaction with
other nmh processes.
I did? When I went back and looked
And the exact gotcha involved, from 'nman rcvstore':
BUGS
If you use the Unseen-Sequence profile entry, rcvstore could try to
update the context while another
nmh process is also trying to do so. This can cause the context to
become corrupted. To avoid this,
do not use
In message 20130216223055.9b6af360...@charybdis.ellipsis.cx,
Joel Uckelman uckel...@nomic.net wrote:
Thus spake Ronald F. Guilmette:
For example, I've had this spam-filing recipe in my .procmailrc for ages:
:0w: Mail/sp/$LOCKEXT
* ^X-Bogosity: Spam, tests=bogofilter
|
For my purposes, it would be extraordinarily helpful if, in the
next release, the -file option for the inc command would accept
as its argument some sort of magic token which would serve to
represent stdin. (By tradition, in many other programs this is
most often represented by a single dash.)
The normal way to handle your second problem is to set $MHCONTEXT
for the scope of your script. Admittedly, this is not listed prominently
in an ENVIRONMENT section of most nmh man pages (not even nmh itself).
As for the first, you might also look at slocal.
Thus spake Ronald F. Guilmette:
I am signed up for many mailing lists, including this one, which
I do not actually read on a routine basis, but which I like to
archive locally using appropriately named MH folders that reside
underneath my own ~/Mail directory.
Of course, as far as the MH
In message 20130215220128.1c444c...@db.pthbb.org,
Jerrad Pierce belg4...@pthbb.org wrote:
The normal way to handle your second problem is to set $MHCONTEXT
OK. To what?
for the scope of your script.
I don't understand. Please elaborate.
Admittedly, this is not listed prominently
in an
In message 20130215220249.20dec360...@charybdis.ellipsis.cx,
Joel Uckelman uckel...@nomic.net wrote:
Thus spake Ronald F. Guilmette:
I am signed up for many mailing lists, including this one, which
I do not actually read on a routine basis, but which I like to
archive locally using
Can't you use rcvstore for this?
I don't know. Can I?
This (rcvstore) is yet one more thing that I never even knew about until
today.
So, some meta-observations ...
As others have alluded, inc is a tool designed to be run interactively
by humans (although many times it's being run by a
15 matches
Mail list logo