Minor patches for builds against ancient platforms

[M. Balridge]

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