Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log was locked for 95 seconds (rotating while syncing)
Timo recently explained to me it's probably caused by slow I/O or processing. This explanation is consistent with my observation that the users who get these messages have jumbo mailboxes.
I do know that this little box of horrors has 200-300MB mbox INBOXes on an ext3 filesystem formatted in 2005. I am very nervous about converting them to Maildir at this point. If I could get someone (or something) to the site and replace it with something much more suitable, I could have these people join the 21st Century.
You can disable dotclock altogether, but I don't think this is what you meant. You can use locking method "dotlock_try" rather than "dotlock" -- the former will ignore quota/permissions problems and plow on. (It still logs it.) You could also align luser's mail folder group with with luser's GID, which is usually what I do.
What I meant was, are certain types of filenames "blocked" by policy from being created via IMAP commands? I'm sure I could run a few tests to answer this for myself, or better still, go through Timo's code.
Maybe locks are created even when files don't exist as there may be a race condition where another process is creating/deleting it at the same time.
Sure, I could see that. In reading through the locking code of sendmail, dovecot, UW-IMAPD, and procmail, it's clear that locking files under UNIX is chaotic and filled with no small amount of voodoo. And naturally, opinions and implementations radically disagree. (How sensible it was of Timo to make it a RUNTIME configuration option in dovecot.)
I appreciate your reply, Joseph.
48 hours after switching half of the userbase to dovecot, I am not seeing any serious problems, and already people are more often than not very pleased by the improved performance and responsiveness.
One last problem area is that many users have soft-links to mailboxes located on a second drive, but these never appear in folder enumeration lists or they appear grayed out in SeaMonkey/Thunderbird.
I've tried just symbolically linking to directories containing other mboxes, but sometimes it works, and sometimes it doesn't. I wonder if there's paranoia checking in the code that follows symbolic links to ensure that uids/gids of the "owning" directory and the linked-to directory (or files within it) are the same.
I'm still trying to absorb all of the documentation for dovecot.
=M=