Apologies if this shows up twice. If so the first is garbled.
/bin/mail through telnet on NT keeps crashing, and when this has
happened before partially composed mail has been sent. Grrrr.
It doesn't look like that happened this time, but know way to
know for sure.
On Thu, 8 Jul 1999 02:22:48 -0400, era eriksson <era(_at_)iki(_dot_)fi> wrote:
On Wed, 7 Jul 1999 19:17:52 -0400, "D. Hammond"
<deh(_at_)crisp(_dot_)openix(_dot_)com>
wrote:
>
> [...]
You mean like this?
[...]
3. If ftp was successful, the cron job sends a command by mail
to remove the file from the ISP. (This is the part I was unsure
of. "A message is sent" from home to the ISP "to trigger [removal
of the file]" at the ISP end, yes?)
I guess too much was trimmed trying to reduce my natural verbosity. ;-)
1. Mail addressed to me at my ISP with a certain tag (and from a white
listed sender) is delivered to a separate folder by procmail for
later "delivery" to my oldest son.
2. A nightly cron job at home saves the mtime of his local spool file,
then does 'ncftp -c openix.com:remote_file >>local_spool_file'.
'-c' writes to stdout, so if there is no remote file the mtime on
the local spool file is unchanged.
3. If the mtime has changed on the local file, I take that to mean a
remote file has been retrieved and email is sent back to me at the
ISP, which triggers procmail to rm the remote file.
The mtime and test for existence of remote file are new, and why I was
being overly cautious. The message that triggered 'rm -f remote_file'
used to be sent without bothering to check if there was actually
anything there. Not a big deal, just figured fewer "moving parts" was
better with a process that's not too robust as it. But I'm always
extra cautious until something new has been working for awhile.
[...]
4. Meanwhile, any mail that arrived while this was happening is lost
forever. (Correct?)
Correct. I knew someone would call me on this. He's 10, the white
list is very limited, and the cron job runs in the wee hours of the
morning. It's not at all likely that anyone would *send* him anything
while it's running. We know that there's still a risk that he might
*receive* something at that time.
The last point can easily be remedied by renaming the file at some
point before the ftp executes, so you ftp over a datestamped copy, and
any mail which arrived between the time the spool file was renamed and
it was ftp:ed over is simply left until tomorrow (or whenever your
cron job executes next).
(So procmail would still save to "file" and if it's empty, create a
new one. Meanwhile, "file" occasionally gets renamed to "file-990708"
[for today's file] and ftp only attempts to fetch a file named this
way.)
That's a good idea. Thanks. So I could send another message from
home before getting the remote file, triggering the name change in
another procmail recipe. I think I can handle that. But it raises
a couple more questions. The remote_file should be locked, right?
Can it be done at the start of the recipe like ':0:'? If so, does
this recipe and all others that touch that file need to use the same
lockfile name? Or do I have to execute 'lockfile file.lock; mv file;
rm -f file.lock' in the action line?
> :0
> * three conditions here that adequately identify
> * any messages that trigger this recipe actually
> * come from me.
> {
> :0
> * ? test -f $HOME/.../his_mbox
> {
> LOG=">>>>>>>>> $RCFILE: suitable message $NL"
> :0 ic
> | rm -f $HOME/.../his_mbox
>
> :0
> /dev/null
> }
> :0 E
> /dev/null
> }
>
> It's probably unnecessarily anal to check for the file's existence
> here, but what the hey.
(Actually, it's a complete waste of resources, because rm -f will not
complain or anything if it's not there.)
Right. I knew rm wouldn't complain, but I was unclear whether that
action would satisfy procmail that the message had been delivered, since
it really hasn't. Even though that's what is desired.
> [...]
:0
* your
* three
* conditions
{
:0
* test -f $HOME/.../his_mbox # kept this for the logging
{
LOG=">>>>>>>>> $RCFILE: suitable message$NL"
:0i
| rm -f $HOME/.../his_mbox
}
# If it gets this far, the test was not true (or rm failed)
:0
/dev/null
}
That's better.
Hope this helps,
It always does ... even when just lurking. Thanks.
- Don