On Sat, Aug 02, 2003 at 08:00:15PM -0700, Tim Hasson wrote:
> When running versions of courier-imap higher than 1.6.1 on Coda (ex. 1.7.0, 
> especially when moving/deleting messages through any imap client), I always 
> got inconsistencies with files like courierimapuiddb and pop3dsizelist.
> I read about Coda having problems with link() and someone recommended using 
> rename() instead.

It is not really a problem with link(), Coda just doesn't do
cross-directory hardlinks (which is what maildir uses). Rename is a good
alternative as far as Coda (and AFS) are concerned.

> worked for a week or so and again inconsistencies and problems with the 
> courierimapuiddb file. pop3dsizelist is not a problem anymore however.
> 
> Do you have any suggestions? Do you think this could be related to the
> change I made in liblock/mail.c ? Any help would be greatly
> appreciated. I attached some info from the coda logs and checkup with
> coda's repair tool to see which files where accessed/altered. 
> hope it helps.

courierimapuiddb is a shared file which can more easily get conflict. My
local version of Mutt has worked fine for years, but after the latest
upgrade I conflicts and lock problems as well because they added this
header cache database. It is kind of funny, maildir was designed to work
reliably in a lockless environment, but it isn't terribly efficient for
an email client (or imap server) because all messages need to be opened
and read individually to get the headers.

So to improve performance, developers are adding these shared top-level
databases that contain header summaries and such, but design them in
such a way that they require working locks and guaranteed exclusive
access.

Now, Coda isn't perfect, it (often too quickly) decides that something
is wrong and marks things as a conflict. We should theoretically never
have a conflict as long as a single client is responsible for modifying
files.

There are many little corner cases where a completely valid
reintegration is rejected. A lot were fixed in 6.0.0, but I'm still
finding new cases. (I've been working on a nasty one for the past 5 days)

> coda1# ll /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.Trash/*
> /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.Trash/global:
> total 7
> -rw-r--r--   1 vpopmail nobody        211 Aug  1 15:37 courierimapuiddb
...
> /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.Trash/local:
> total 7
> -rw-r--r--   1 vpopmail nobody        138 Aug  2 15:15 courierimapuiddb

That is not your problem, just look at the pending reintegration log,

> Create  ???/tmp/1059862522.7440_imapuid_22.coda1
> Store   ???/tmp/1059862522.7440_imapuid_22.coda1 (length = 138)
> Remove  /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.Trash/local/courierimapuiddb
> Rename  ???/tmp/1059862522.7440_imapuid_22.coda1 
> (to: /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.Trash/local/courierimapuiddb)

I.e. the operations that create the new version of courierimapuiddb have
not yet been reintegrated. So it is not surprising that the server still
has the old version.

It is the first operation in the reintegration log that 'triggered' the
conflict.

> repair > listlocal
> local mutations are:
> Rename  /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.BulkMail/cur/1059861761.M754753P7376V00000000I014F31C7_0.coda1,S=6062:2, 
> (to: /coda/vpopmail/domains/aidasystems.com/adeeb/Maildir/.BulkMail/cur/1059861

I have to guess a little here, my guess is that you have a singly
replicated volume with a 5.3.20 server. These servers use a too strong
test for the directory version vector. Operations conflict with previous
ones on the same directory. So it probably just reintegrated another
rename which bumped the version vectors and as a result the current
rename on the same directories failed and triggered a conflict situation.

That problem was fixed in 6.0.0, even if you can't or won't run 6.0.x
clients you probably should upgrade your servers.

Jan