On February 5, 2002 at 10:19, Don wrote:
I'm attemting to keep an archive automatically up to date using
a .forward file. When I use the -add option, the archive is always
one e-mail behind. ie, If the mail box has 4 messages, only 3 will
display on MHonArc. When message #5 comes in, MHonArc will display
4 messages. If I remove the -add option, which has the effect of
rebuilding the entire archive, the archive is kept up to date. This
works for now, but as archives get very large this would of course be
problematic. Any Ideas?
My initial hunch tells me it may have to do with the mechanics on how
sendmail is invoking things. Does sendmail invoke each forward
component in sequence (and if so, what is the order), or in parallel?
If there is some parallelization, there could be race conditions
between when sendmail appends beta's spool file to when mhonarc (via
webnewmail) reads the spool file.
If sequence, it is possible that sendmail calls "|./webnewmail"
first before appending to beta's spool file.
You could easily do some tests to find out what is going on by
replacing webnewmail with a simple program (like cat) that just
dumps the contents /var/mail/beta to some temp file. Then
you can examine the temp file to see if the new message actually
exists or not.
.forward file: \beta, "|./webnewmail"
Snippet of ./webnewmail:
@ARGV = ("-quiet",
"Project Beta Date Index (by reverse date)",
"Project Beta Thread Index (by reverse date)",
With what you have, using webnemail in the .forward is useless. I.e.
The .forward file tells sendmail to pipe a copy of the message to
webnewmail, but the @ARGV settings is telling mhonarc to read from the
spool area. I.e. Standard input of webnemail (which contains a copy
of the new message) is being ignored. Hence, you are relying on
sendmail to append the new message to /var/mail/beta before
webnewmail is called.
With what you have, it is probably better to use a cron job, which I
generally advocate. With cron, you can managing load better and deal
with problems better.