Two separate bugs fixes, against current 2.3 CVS.
The missing i++ means that we would have failed to RESERVE some messages
where a given GUID appears multiple times in a mailbox. Not a huge deal.
The missing (i count) was potentially serious: we fall off the end of
the ids array where
On Mon, 24 Sep 2007, Bron Gondwana wrote:
Picture if you will...
sync_client finds a message missing on the replica during a mailboxes
event and causes a sync_combine_commit to be called on the replica to
absorb the new messages.
* cyrus.index is re-written with new cache_offset values for
Bron Gondwana wrote:
On Mon, 24 Sep 2007 23:39:52 -0400, Ken Murchison [EMAIL PROTECTED] said:
Yes, my for() loop test was incorrect, and SHOULD BE:
(index_list-count max_count)
(msgno = mailbox-exists)
So, for mailbox-exists=1000, and max_count=1000, when we exit the
On Mon, 24 Sep 2007, Ken Murchison wrote:
Attached is my rewrite against CVS. I removed duplicate code that
resulted from having one for() loop with a special case if() inside (It
not uses a for() loop nested inside a do() loop). The patch doesn't
look simpler because my version of diff
On Tue, 25 Sep 2007, David Carter wrote:
I imagine that a single GUID appearing in cyrus.index and cyrus.expunge
is bad news. sync_server needs to know about the expunge index. It did
in my original code base, but replication got merged before delayed
expunge.
Single _UID_ appearing in
On Tue, 25 Sep 2007 12:15:04 +0100 (BST), David Carter [EMAIL PROTECTED]
said:
On Tue, 25 Sep 2007, David Carter wrote:
I imagine that a single GUID appearing in cyrus.index and cyrus.expunge
is bad news. sync_server needs to know about the expunge index. It did
in my original code
On Tue, 25 Sep 2007 07:11:36 -0400, Ken Murchison [EMAIL PROTECTED] said:
Bron Gondwana wrote:
I'm afraid I still don't see how your code addresses the case where there
turn out to be no more messages with higher UIDs which need uploading even
though we've hit exactly max_count messages.
