Hi,

Thank you very much for your reply.

Quoting Jan Harkes <jaharkes_at_cs.cmu.edu>:

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

I made sure I had disabled locking in courier-imap prior to this posting. It is 
a configurable option in imapd config file (as far as courier is concerned).

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

Upgrading to Coda Server ver 6.0.2 fixed the problem with courierimapuiddb 
causing a conflict everytime it has to be regenerated (when deleting some 
messages or moving them from folder to folder). I believe I have not seen 1 
conflict in regards to the courierimapuiddb file, although, some users reported 
getting similar error messages from the imap server at times like: Sorry, 
cannot open the message, it's gone! :( I thought I was close and had that 
worked out.

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

Close enough. I was running 5.3.20 server/client on two FreeBSD 4.8 machines 
for a little while. But of course before writing this email I have upgraded to 
6.0.1 from tarball on coda's ftp server. I had maintained the older 5.3.20 
client since I didn't want to mess with kernel/lkm recompile for now. And like 
I said above, I also upgraded to 6.0.2 two days ago. Seems like we're getting 
closer...

I agree with you that it is a funny thing that Maildir was designed especially 
to work better than the mbox format over networked filesystems, such as NFS 
which unfortunately is the only workable filesystem for such setup at the 
moment, and it's not the best. I made a big mistake and put all of our clients 
on the new Coda 6.0.2 system thinking I might get away with it for a few days 
without having to repair inconsistencies, but yesterday and today I started 
getting some calls from people complaining there clients says "you have 3 new 
messages" but they dont see any new messages in any of their folders. Looking 
at codacon didn't show any conflicts/inconsistencies, neither does "ls -
lR /coda/vpopmail | grep root". Restarting venus on coda2 seems to have solved 
some problems and I am now seeing messages that I didn't see before, but it 
seems that this problem is intermittent. Also, to a fewer mail users, some get 
incorrect message count. Like when they get a new message, it says you have 3 
new. It is strange.

Anyways, I think I learnt my lesson and I got to wait till after business hours 
to move my mail domains back to the ufs / partition on freebsd for now. I am 
thinking of leaving 1 or 2 domains on Coda's volume still for testing.

Question: Do you think upgrading the coda lkm for the new venus client (6.0.2) 
may make any difference as to what we are addressing?

Respectfully,
Tim Hasson


> Jan
> 
> 
>