No problem Bron!! Very thankful for your time and your help!!.
I have some ideas/questions about the synchronous replication too for commenting you… I have never heard about Cassandane (only to Ellie in this list or Github commit comments) :) but will check it :) :) although I’d need to wait the holidays to come, in order to be more free for all these :) Cheers! Egoitz Aurrekoetxea Dpto. de sistemas 944 209 470 Parque Tecnológico. Edificio 103 48170 Zamudio (Bizkaia) ego...@sarenet.es <mailto:undefined> www.sarenet.es <http://www.sarenet.es/> Antes de imprimir este correo electrónico piense si es necesario hacerlo. > El 16 jul 2019, a las 2:04, Bron Gondwana <br...@fastmail.fm> escribió: > > Sorry for not getting back to you yesterday. I was on my way back from > vacation and had family commitments all last night. > > Regarding contribution - the very best thing to do for a case like this is to > build Cassandane tests which isolate the issue :) I'll see if I can get that > done today. > > Cheers, > > Bron. > > On Tue, Jul 16, 2019, at 02:34, Egoitz Aurrekoetxea wrote: >> Hi Bron! >> >> Sorry for answering so late I had the thought I answered you before…. I’m >> slightly stressed these days... >> >> I answer below in green bold for instance….. >> >> >> >> Egoitz Aurrekoetxea >> Dpto. de sistemas >> 944 209 470 >> Parque Tecnológico. Edificio 103 >> 48170 Zamudio (Bizkaia) >> ego...@sarenet.es >> www.sarenet.es <http://www.sarenet.es/> >> >> Antes de imprimir este correo electrónico piense si es necesario hacerlo. >> >>> El 14 jul 2019, a las 14:36, Bron Gondwana <br...@fastmailteam.com >>> <mailto:br...@fastmailteam.com>> escribió: >>> >>> On Wed, Jul 10, 2019, at 19:11, Egoitz Aurrekoetxea wrote: >>>> Good morning, >>>> >>>> In previous thread (with the title slightly incorrect) I talk about an >>>> issue suffered some day with Sieve script and folder subscriptions. The >>>> Sieve part, was related to the migration, so for the moment let’s forget >>>> about it (for me at least) as it has never reproduced again since then. >>> >>> Sorry, I missed the previous thread. Did you mention which version of >>> Cyrus you are running? There's clearly a bug and it would be good to know >>> which version(s) it affects. >> >> >> I think I have specified all these details (including what the previous >> thread was saying) in the answered mail this morning… I think it's all >> there… the version was 3.0.8…. If is not all or you need something, please >> tell me and I’ll try my bests for providing you all the info you need.. >> >> >>> >>>> About the folder subscription issue, I think I got something, at least a >>>> close approximation... When a user causes in mua a rename mailbox (a >>>> rename for a folder caused by a folder move in hierarchy), after the own >>>> rename, if folders were subscribed “should” (for the "plain user" at >>>> least) become subscribed in the new path. It seems that after a user >>>> rename in Cyrus the new folder is automatically subscribed (even if no >>>> subscribe command is sent by the mua). But this, does not cause in the >>>> replica (in the slave, if SUB is not sent by the client) a >>>> sync_apply_changesub() or something like entering in the “ >>>> move_subscription” condition in mboxlist_renamemailbox(), and then, the >>>> folder is properly renamed but not subscribed in the slave. I think this >>>> is what I’m suffering. Obviously, if after a rename the mua sends a >>>> subscribe too, no issue is seen. I think the problem happens when a >>>> mailbox rename happens and a SUB is not send later. >>> >>> Subscriptions aren't automatically renamed when a folder is renamed, but >>> they should be automatically renamed for a user rename. Intermediate >>> replicated states can be bit messy due to race conditions with replication, >>> but I believe it should always wind up in the final correct state. If not, >>> that's a bug for sure! >> >> This tests are some days ago… I’m slightly confused now because I don’t >> remember it exactly… >> >>> >>>> An example : >>>> >>>> The folder domain.com >>>> <http://domain.com/>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG >>>> is moved (renamed) to trash. >>>> >>>> May 16 16:16:50 mx6c imap[83976]: conversations_rename_folder: renamed >>>> domain.com >>>> <http://domain.com/>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG >>>> to domain.com <http://domain.com/>!user.parta^partb.Trash.XINGANG >>>> May 16 16:16:50 mx6c imap[83976]: Rename: domain.com >>>> <http://domain.com/>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG >>>> -> domain.com <http://domain.com/>!user.parta^partb.Trash.XINGANG >>>> May 16 16:16:50 mx6c imap[83976]: Deleted mailbox domain.com >>>> <http://domain.com/>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG >>>> >>>> In the master (sync), the folder in Trash is subscribed but in the slave >>>> it is not, and remains subscribed the folder in the original location in >>>> the “____.sub” file. >>> >>> This might just be a matter of failing to sync_log the subscription in that >>> codepath. Hmm... >>> >>> But there is a question of whether we should even be renaming the >>> subscription - RFC3501 is a little silent on this issue, but it does say in >>> a couple of places that the server MUST NOT remove a subscription even if >>> the mailbox with that name doesn't exist, which makes renaming >>> subscriptions a bit unclear. I'll check in with the authors of >>> draft-ietf-extra-imap4rev2 and ask for this to be clarified next time >>> around! >> >> >> That’s it Bron.. it was strange… anyway… you know, when you try to debug an >> issue like the commented you do a closer inspection to all this behaviour, >> you know…. Although as said before, perhaps it’s better to talk about >> today's examples… I got them more recent…. >> >> >>> >>>> A diff between the master (replication client) .sub file and the slave’s >>>> one is (mx5 is the master, the client and 6 the slave): >>>> >>>> --- subscripciones-mx5c/parta.partb.sub 2019-07-10 08:47:29.000000000 +0200 >>>> +++ subscripciones-mx6c/parta.partb.sub 2019-07-10 08:48:08.000000000 +0200 >>>> >>>> +domain.com >>>> <http://domain.com/>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG >>>> -domain.com <http://domain.com/>!user.parta^partb.Trash.XINGANG >>>> >>>> Perhaps a move_subscription to one or sync_apply_changesub should be >>>> forced in order to fix it?. I have seen issues with Outlook 2016 and >>>> Thunderbird… both mua… perhaps by RFC they should send the SUB command >>>> but… it’s the only theory I could arrive to… I have a ton more cases like >>>> this one.. Data gets properly handled but subscriptions have this issue >>>> (perhaps we could say is a mua issue but….).. >>> >>> Bron. >> >> >> Thanks a lot! >>> -- >>> Bron Gondwana, CEO, Fastmail Pty Ltd >>> br...@fastmailteam.com <mailto:br...@fastmailteam.com> >>> >>> >>> ---- >>> Cyrus Home Page: http://www.cyrusimap.org/ <http://www.cyrusimap.org/> >>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ >>> <http://lists.andrew.cmu.edu/pipermail/info-cyrus/> >>> To Unsubscribe: >>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus >>> <https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus> >> >> ---- >> Cyrus Home Page: http://www.cyrusimap.org/ >> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ >> To Unsubscribe: >> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > > -- > Bron Gondwana > br...@fastmail.fm <mailto:br...@fastmail.fm> > > > ---- > Cyrus Home Page: http://www.cyrusimap.org/ <http://www.cyrusimap.org/> > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > <http://lists.andrew.cmu.edu/pipermail/info-cyrus/> > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > <https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus>
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
