Re: formail -D & -n (was Procmail Version 3.14 released)

[Philip Guenther <http://www.gac.edu/~guenther>]

http://dummy.us.eu.org/robert (robert) writes:
> > From: Philip Guenther <http://www.gac.edu/~guenther>
> > Date: Tue  Nov 23,  1:14am
> >
> >             Changes to formail:
> >                - Prevent corrupt idcaches by suppressing the -n option when
> >                  splitting with the -D option
>
>Hi.  The above caught my eye.  I have some questions:
>
>1) What if the "formail -D" is done inside a script specified by "formail -s",
>   but the -n is also being used?  (I.e., "formail -n -s blah" where "blah"
>   is doing a "formail -D".)  Will the ids get corrupted in that case as
>   well?

If some locking doesn't take place inside blah, then yes, the ID cache
could be corrupted.


>2) Will this "feature" always persist in the future?  I currently use
>   "formail -D #### messids -n ### -s" in one of my scripts and I find the -n
>   feature great for my particular application.

I would expect this change to remain in place forever.  The accesses to
the ID cache must be serialized to avoid corrupt caches.  If your usage
is without a program after the -s flag, then the -n was just asking for
trouble and of marginal benefit anyway.  If your are using the above with
a program argument and you really want to parallelize the invocations you
should either a) remove the duplicates earlier, or b) do the duplicate
removal inside the program (i.e., inside "blah" above) with a lockfile
around it.  At least then the rest of "blah" can be handled in parallel.


>(As it turns out, I was worrying about #1, and I happened to have found your
>mail message in the procmail mail archive.  I was thinking of adding some
>lock mechanism to assure that I avert the corruption problem.)

Bingo.


Philip Guenther