procmail
[Top] [All Lists]

Re: Ignoring and/or Bouncing mail?

1996-08-11 22:35:51
    lockfile badguys.lock
    vi badguys
    rm -f badguys.lock

Is there a similar way to protect .procmailrc itself while editing it?
I usually edit ".newprocmailrc" and then hope a "mv" doesn't cause
trouble.  But sometimes I'm lazy  :-)  And I don't trust mv to
guarantee that one or the other of the old/new files will be found,
especially over NFS.

"mv" does a "link" to the new name and an "unlink" on the old name, so
it is atomic across NFS.  You needn't worry. 

The locking problem you hear about with NFS have to do with "flock"
and "lockf" calls, which must be implemented across the network.

In fact, would badguys.lock even work over NFS?  (Most general
case would be MDA on one machine, the lockfile on a second, and
the user on a third, all separated by NFS interfaces, I guess.)

Yes.  badguys.lock is created by linking from a temporary file name
to the desired lock file name.  Again, since it is a link command,
it is atomic, even over NFS.

BTW, I'd recommend the "addbadguy" script Alan suggested rather than
the three-liner quoted above, because the latter could leave the
thing locked for hours if you get distracted while editing.

I agree :^) since it is how I implemented the "disable autoacks" and
"enable autoacks" commands part of my commands.rc library file.
(send me an email with the subject of "send procmail library").

_____________________________________________________________________
Alan Stebbens <stebbens(_at_)sgi(_dot_)com>      http://reality.sgi.com/stebbens
Digital TV, Silicon Interactive Group,  Silicon Graphics, Inc.  (SGI)
M/S:9L991,     2011 N. Shoreline Blvd.,     Mountain View, CA   94043
PGP Key Fingerprint: 94 A7 4B AB 1C F0 4D 92  DD BC B5 D7 11 A0 DC B3

<Prev in Thread] Current Thread [Next in Thread>