dovecot - Sep 2010 - dovecot-uidlist: Duplicate file entry at line

Hi All,
we are experiencing another strange problem after upgrading to 2.0.1 
from 1.2.

Many people's client aree-retrieving mail from server due to some 
problem with dovecot-uidlist file.
Looking at log file seem that all file content is sometime duplicated 
and appended to the and of same file.
It look as another process was accesing and trying to modify uidlist table.
Our setup has a load balance (dovecot director) and three backend 
server. All of them use 2.0.1.
MTA is a cluster of postfix that deliver mail to load balancer by LMTP.

How can I collect some more information? or, better, solve it?

Regards

Luca

PS: Backend configuration is:
# 2.0.1: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.26-2-686-bigmem i686 Debian 5.0.5
auth_master_user_separator = *
auth_verbose = yes
disable_plaintext_auth = no
mail_location = maildir:~/Maildir
mail_plugins = $mail_plugins notify mail_log quota
managesieve_notify_capability = mailto
managesieve_sieve_capability = comparator-i;octet 
comparator-i;ascii-casemap fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex 
imap4flags copy include variables body enotify environment mailbox date 
spamtest spamtestplus virustest
passdb {
   args = /etc/dovecot/dovecot-sql.conf.ext
   driver = sql
}
plugin {
   mail_log_events = delete undelete expunge copy mailbox_delete 
mailbox_rename
   mail_log_fields = uid box msgid from size
   quota = maildir:User quota
   quota_warning = storage=95%% quota-warning.sh 95 %u
   quota_warning2 = storage=80%% quota-warning.sh 80 %u
   sieve = ~/.dovecot.sieve
   sieve_dir = ~/sieve
   sieve_global_dir = /etc/dovecot/sieve/global/
   sieve_global_path = /etc/dovecot/sieve/default.sieve
}
protocols = imap pop3 lmtp sieve
service auth {
   unix_listener auth-userdb {
     group = dovecot
     mode = 0600
     user = dovecot
   }
}
service director {
   inet_listener {
     port = 8100
   }
}
service lmtp {
   inet_listener lmtp {
     address = 10.194.1.31 127.0.0.1 ::1
     port = 24
   }
}
service managesieve-login {
   inet_listener sieve {
     address = 10.194.1.31 127.0.0.1 ::1
     port = 4190
   }
   process_min_avail = 0
   service_count = 1
}
service quota-warning {
   executable = script /virtual/shared/quota-warning.sh
   unix_listener quota-warning {
     user = vmail
   }
   user = dovecot
}
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
userdb {
   args = /etc/dovecot/dovecot-sql.conf.ext
   driver = sql
}
verbose_proctitle = yes
protocol lmtp {
   mail_plugins = $mail_plugins quota sieve
}
protocol lda {
   mail_plugins = $mail_plugins quota
}
protocol imap {
   mail_plugins = $mail_plugins quota imap_quota
}
protocol pop3 {
   mail_plugins = $mail_plugins quota
}

On Thu, 2010-09-02 at 19:21 +0200, Luca Palazzo wrote:
> Hi All,
> we are experiencing another strange problem after upgrading to 2.0.1 
> from 1.2.
> 
> Many people's client aree-retrieving mail from server due to some 
> problem with dovecot-uidlist file.
> Looking at log file seem that all file content is sometime duplicated 
> and appended to the and of same file.
> It look as another process was accesing and trying to modify uidlist table.
I've heard of some dovecot-uidlist problems, but haven't really figured
out anything that could be wrong.. I guess there's no way you can
reproduce this? Does happen to same user more than once? How many users
is "many"? Does this happen only/mainly to some specific mailboxes
(INBOX, Trash)? Does this happen to more than one same user's mailbox at
the same time? Does this happen to different users around the same time?
> Our setup has a load balance (dovecot director) and three backend 
> server. All of them use 2.0.1.
How did you do it before v2.0?

The maildir code hasn't changed much since v1.2. Hmm. Except that
maildir filenames are now tried to be preserved when copying, so copying
messages elsewhere and back does sound like it could cause this
(although there is code to prevent it)..