On January 8, 2003 at 23:59, "Christopher P. Lindsey" wrote:
# CHANGE: tests if directory exists; saves a system call
:0 Wic
* ? test ! -d $MBOXROOT/mhonarc-users
`mkdir -m 755 -p $MBOXROOT/mhonarc-users`
But isn't the call to 'test' a system call or does procmail handle
it specially. If not, calling mkdir always uses a single system
call while your method uses one or two system calls.
Boy, we can't put anything past you. :)
Traditionally, 'test' has been a less expensive call than 'mkdir', so
you only have an expensive call when both need to be run. I guess the
comment should have been
I'm unsure about the expense. Both will at least do a stat().
Hence, mkdir -p does an implicit stat first to see if the pathname
exists. If so, it quietly exits.
Unfortunately, this will not work. The message-id cache will cause
the message to be quietly dropped when delivered back to the archive
account. I.e. There is an initial formail rule that checks the
message-id cache, and if the id exists, the message is quietly dropped.
Ahh. I suppose a way around that is to check if the message-id is in
the cache before adding it, and only adding it after successful delivery.
A gotcha is that if it is a cross-posted message and it gets delivered
to one archive, but fails for another (probably and improbable event).
Does formail support an action of check, but do not add? And then
just an add to the cache? I'm not sure, so a custom script would
be needed.
Something really screwing has to happen for an delivery error to occur,
but of course, anything can happen (like out-of-disk space). I'm unsure
that requeuing (ignore the message-id cache issue) is the best solution,
with one reason due to the existence of different MTAs.
OK. Just thought I'd ask. :)
It's a good question, but the answer is not clear. Something to
consider is if delivery error does occur, is the system in a state
that any kind of error recovery is hopeless?
It could be possible if that all I/O is over NFS, and the NFS server
is down, some kind of error recovery could occur, like bouncing messages
to an admin address, or queuing the messages to a local temp file
to be processed later.
In sum, I think robust error handling would require some work, and
of course, it would be for rare cases.
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
