Yes, I noticed the comment, but I thought it was wrong.

The problem was that we had quite a number of upas/fs's and scanmails
running and it was because one of them had a problem and kept a
/mail/tmp/L.mbox file locked. All other ones kept waiting for that
(although all of them were using different "mboxes" created by the
piped script at /mail/tmp/$pid.blah.blah

Making this change made problems go away, and I didn't notice any
problem in imap so far. I guess I'll have to reread the imap source to see
if it really requires one lock per dir instead of one per mbox, but even so,
I think imap should use a different lock for that, it's upas/fs the one I'm
talking about.

thanks for the hint

On Apr 18, 2013, at 4:04 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> i think the comment above the function is important
> "we use one lock per directory".  it's been a long time since
> i worked on nupas, so i don't recall all the details, but
> iirc, imap4d relies on having one lock per directory.