NOTE I just realized I used "consecutive" a couple times in my previous
posts, whereas I did mean to say "concurrent". Bad, bad screw up.
Sorry for any confusion caused.
On Thu, 2008-01-31 at 20:57 +0000, Arthur Dent wrote:
> On Thu, Jan 31, 2008 at 09:36:29PM +0100, Karsten Bräckelmann wrote:
> > On Thu, 2008-01-31 at 19:31 +0000, Arthur Dent wrote:
> > > Apologies to everyone for wasting OT bandwidth. I have just re-read man
> > > procmailrc and realised that a "copy" recipe is not considered to be a
> > > delivery action and therefore does not need a lock.
> >
> > Uhm, where did you read that? Clearly, even a copy can deliver mail.
>
> From man procmailrc:
>
> "You can tell procmail to treat a delivering recipe as if it were a
> non-delivering recipe by specifying the ‘c’ flag on such a recipe.
> This will make procmail generate a carbon copy of the mail by
> delivering it to this recipe, yet continue processing the rcfile."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It is my understanding, that the above does *not* alter the meaning of
the procmail action. Delivery to a file still is delivering. IMHO this
merely tries to verbosely express the meaning of the phrase "copy".
Again, consider the basic copy example:
:0 c:
backup
I do insist on locking, because this receipt will append the message to
the mbox file. Which is a simple write modification, and needs to be
atomic. While one process (procmail) is writing to that file, no other
process (a second procmail, your IMAP server, etc) may work with that
file. Hence, locking.
Oh, and please note that the "identical" example from 'man procmailex'
explicitly assumes Maildir, and thus does not need locking...
> > > Removing the lock from my backup copy solves the problem.
> >
> > As per the log snippet from your previous post: Procmail can't acquire
> > the lock for some reason. But it does not complain that it couldn't
> > deliver. The mail should have been appended to the backup mbox
> > regardless.
> >
> > So why does the lock fail? Wrong permissions for the dir?
>
> Well, good question. All I can say is that *every* mail gets written to this
> backup file (and always has for about the last 2 years). It is only those
> mails that match the "numerical" spams that cause this error.
According to your other post, this probably is related to the "sample"
you used to check.
The backup copy still should be protected by a lock. Even more so given
your use of fetchmail, expecting to process up to 20 mails within a
short amount of time.
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
