On Sat, Mar 24, 2007 at 03:42:45PM +0100, Dallman Ross wrote:
On Thu, Mar 22, 2007 at 04:02:24PM +0100, Axel Thimm wrote:
Since procmail has a first-delivery-stop design, I'm cheating as
everybody else by making extensive use of blocks (w/o a "c" flag,
Not sure why you call that "cheating," but whatever.
e.g. non-forking). In order to still be able to tell whether something
had been delivered I'm using LASTFOLDER. So for example if after the
block processing the mailing lists is done I can query LASTFOLDER to
see whether the mail has been delivered at least once. and since most
actions happen within blocks I more or less close the recipe with
:0
* $ ! ${LASTFOLDER+!}
{ HOST=stop }
The setup worked for the last decade, but I never had any filesystem
issues in this decade. I now had a situation where the underlying
filesystem became read-only. This lead to delivery failures [. . . .]
and the check of LASTFOLDER implies that it was delivered which it was
not! So the mail is lost.
[. . . .]
I think setting LASTFOLDER even when the action fails is a bug in
procmail, or at least undocumented behaviour. Nevertheless I can't
even find something to work around it. Do I need to pair every
delivery action with an :0 e action marking success or failure?
Well, I don't know of any documentation that implies that LASTFOLDER
is equivalent to a zero exit status.
The documentations says "This variable is assigned to by procmail
whenever it is delivering to a folder or program. It always contains
the name of the last file (or program) procmail delivered to. If the
last delivery was to several directory folders together then
$LASTFOLDER will contain the hardlinked filenames as a space separated
list."
The definitely wrong part is "It always contains the name of the last
file [...] procmail delivered to" implying that LASTFOLDER points to
successful deliveries.
Why don't you check the exit status? Hmm, I just checked, and a
failed write doesn't affect the exit status. Hmm.
If the exit status were not 0 there wouldn't be an issue to start with
:)
Well, the e flag does work. If you're having file system trouble,
that would seem to be a useful thing to do.
:0
* conditions
{
:0:
badpermshere
:0 e:
errorfolder
}
Anybody see a cleaner way?
That was what I meant with "Do I need to pair every delivery action
with an :0 e action marking success or failure?". I hope there is a
better non-hacky way to do that.
(I think you should find out what's going wrong with your filesystem.)
Of course, but once in a decade the fs is allowed to have troubles
like a bad disk or fs full. procmails does look a bit fragile in this
light, especially I one now has to manually check all recipes for
success or failure like above. :/
--
Axel.Thimm at ATrpms.net
pgpyLgdNrXuc0.pgp
Description: PGP signature
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail