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….. > > > sarenet > *Egoitz Aurrekoetxea* > Dpto. de sistemas > 944 209 470 > Parque Tecnológico. Edificio 103 > 48170 Zamudio (Bizkaia) > ego...@sarenet.es > 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> 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!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!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG to >>> domain.com!user.parta^partb.Trash.XINGANG >>> May 16 16:16:50 mx6c imap[83976]: Rename: >>> domain.com!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG -> >>> domain.com!user.parta^partb.Trash.XINGANG >>> May 16 16:16:50 mx6c imap[83976]: Deleted mailbox >>> 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!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG >>> -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 >> >> >> ---- >> 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 > ---- > 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
---- 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
