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
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.