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
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
We find all the fun bugs :)
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 each message
*
On Mon, 24 Sep 2007, Bron Gondwana wrote:
Do you guys suggest anything? Ideas I've come up with include:
Ho hum. My original two phase expunge code had separate expunge.index
and expunge.cache files, which keeps cache entries for expunged messages
well out of the way. I think this is
On Mon, 24 Sep 2007 08:20:50 +0100 (BST), David Carter [EMAIL PROTECTED]
said:
On Mon, 24 Sep 2007, Bron Gondwana wrote:
Do you guys suggest anything? Ideas I've come up with include:
Ho hum. My original two phase expunge code had separate expunge.index
and expunge.cache files, which
On Mon, 24 Sep 2007, Bron Gondwana wrote:
Any reason to actually keep them though? It's not as if unexpunge is
common enough to be worth optimising, and they're all auto-generated
content that we can recreate from the message if needed.
My original motivation was user access to expunged
