M. Fioretti wrote Tuesday, September 25, 2007 10:04 PM:
On Tue, Sep 25, 2007 08:49:28 AM -0700, Bart Schaefer
(barton(_dot_)schaefer(_at_)gmail(_dot_)com) wrote:
strings msgid.cache | more
This gives:
# strings msgid.cache | grep -v '^<'
d(_at_)mail(_dot_)gmail(_dot_)com>
382c51cb8c6f250(_at_)mail(_dot_)gmail(_dot_)com>
meaning that these are the only two lines which don't look as normal
"<some-long-semi-random-string-in-brackets>"
procmail: Error while writing to "email_base_dir/INBOX/in-waiting"
My guess would be that some earlier filter in your procmail
config is damaging the messages so that they appear not to have
any message-id
My guess is there is no native locking on msgid.cache. I won't
get into whether the OS is supposed to be writing to the file
atomically -- I do not know. But if you really want an uncorrupted
cache file, you might need to go to using a global lockfile around
the formail recipe. (I believe David Tamkin has called a
global that's set and then unset manually in the rcfile a
"regional" lockfile. I kind of like that terminology.)
E.g., here's something I was using for a while to weed out
duplicates:
LOCKFILE = global.lock
:0
* ? formail -D 8192 msgid.cache
duplicates
LOCKFILE # unset
There are arguments for and against such. I've read both
sides, but I'm not the right one to be an informed advocate.
--
dman
____________________________________________________________
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