Axel Luttgens <axelluttg...@swing.be> wrote:
> But I fear I don't understand your problem description.
> Could you elaborate?

Hi Axel,

The issue is that the procmail port on FreeBSD doesn't acquire a dotlock when it's the default lock file (/var/mail/username.lock). It prints that it's bypassing the dotlock and just does a lockf() lock after. Looking in the code for procmail, it seems that it's being too clever with a bunch of checks and so it doesn't try to get the lock -- it's decided it doesn't want to before doing it.

The permissions and runtime environment permit the lock, and the same lock is acquired correctly by dovecot when writing to the inbox. I'm doing dotlock and then lockf() locking in all the mail software.

procmail's checks only seem to apply to the default lock file for the inbox. If I specify an alternate name in the .procmailrc for the $ORGMAIL delivery of the message, then it will acquire any other lock I ask, including an alternate name in the /var/mail directory.

I'll dig into the procmail sources as needed to resolve it, but I had hoped that I could get dovecot to lock with a different filename, because that would resolve the issue with minimal hackery...

Cheers,
Chris

--
Chris Saldanha
Parliant Corporation

Reply via email to