On Sat, Aug 13, 2016, at 03:12 AM, Kenneth Marshall wrote:
> Hi Ellie,
>
> I tried the patch and it did print the warnings on the replica.
> Unfortunately,
> it looked like it was looping on the master (sync_client) and the updates
> that
> could be made were not. I had to rollback to the dying ve
On Sat, Aug 13, 2016, at 03:12 AM, Kenneth Marshall wrote:
> On Wed, Aug 10, 2016 at 12:30:03PM +1000, ellie timoney wrote:
> > On Tue, Aug 2, 2016, at 02:14 PM, Kenneth Marshall via Info-cyrus wrote:
> > > On Tue, Aug 02, 2016 at 12:34:13PM +1000, Bron Gondwana wrote:
> > > > 2.3.2 wasn't versio
On Wed, Aug 10, 2016 at 12:30:03PM +1000, ellie timoney wrote:
> On Tue, Aug 2, 2016, at 02:14 PM, Kenneth Marshall via Info-cyrus wrote:
> > On Tue, Aug 02, 2016 at 12:34:13PM +1000, Bron Gondwana wrote:
> > > 2.3.2 wasn't version 10, it was version 7! It would have upgraded
> > > through 8, 9,
On Tue, Aug 2, 2016, at 02:14 PM, Kenneth Marshall via Info-cyrus wrote:
> On Tue, Aug 02, 2016 at 12:34:13PM +1000, Bron Gondwana wrote:
> > 2.3.2 wasn't version 10, it was version 7! It would have upgraded through
> > 8, 9, 10 - and maybe you needed to reconstruct to get GUIDs for those
> > ve
On Tue, Aug 02, 2016 at 12:34:13PM +1000, Bron Gondwana wrote:
> 2.3.2 wasn't version 10, it was version 7! It would have upgraded through 8,
> 9, 10 - and maybe you needed to reconstruct to get GUIDs for those versions -
> that sounds familiar.
>
> Bron.
>
Hi Bron,
Is there a way to identif
It's fiddly to tell from git history -- there's a right mess somewhere
during the 2.3 series where it looks like the branch got rebased, or
trashed and reimported, or something like that -- the earlier 2.3
release tags are on commits that are not ancestors of the later ones. I
keep tripping over t
2.3.2 wasn't version 10, it was version 7! It would have upgraded through 8,
9, 10 - and maybe you needed to reconstruct to get GUIDs for those versions -
that sounds familiar.
Bron.
On Tue, Aug 2, 2016, at 12:22, Kenneth Marshall wrote:
> Hi Bron and Ellie,
>
> I think that is what happened.
Hi Bron and Ellie,
I think that is what happened. Replication was working and the 'reconstruct -G'
was optional in terms of working, so some of the oldest mailboxes could be in
that state. I will check the versions and see if there are any older than 10,
but we started with version 2.3.2 so unless
Yeah, could be. In that case then the mailbox needs a reconstruct -G first :(
Version 10 mailboxes have a GUID space available, but I guess they could
wind up zero depending on how they got upgraded in the past.
Bron.
On Tue, Aug 2, 2016, at 11:26, ellie timoney via Info-cyrus wrote:
> I've been
I've been under the impression that Ken's mailboxes were version 10,
which seems like they *should* have guids in them. If this is the
case, then it's interesting that the replica is coming up with zeroed
ones.
If his mailboxes are older than version 10, then it all makes sense,
nothing to see h
You can't sync a mailbox without GUID for messages. You need to upgrade the
mailboxes before you can use them for replication. The GUID is used for
replication - if we allowed zero GUIDs, then every message would deduplicate to
the same message!
On Tue, Aug 2, 2016, at 07:56, Kenneth Marshall
Thanks for passing these reports on!
Initial impression, I don't think this one is as straightforward as the
last one was, unfortunately. :(
Here's the chunk of code that produces those "guid mismatch" SYNCERRORs:
https://git.io/v6JWK
(wait a moment for it to load and it will jump to the lines I
Hi Cyrus Developers,
Thank you for your patch to address the folder move problem between
un-reconstructed mailboxes after the 2.3.16 -> 2.5.9 upgrade. I am
not sure, but it looks like there may be another overly aggressive
check. I keep getting these fatal errors from sync_client:
Aug 1 16:24:16
13 matches
Mail list logo
