I think they said 3.0.8, which is not the latest 3.0, but I also don't think anything about replication/subscriptions/etc has changed since then, so it might as well be
It would also be very interesting to know whether the master and replica definitely both have the same value for "unixhierarchysep". I don't think it should matter? But maybe there's a bug hiding there that's making it matter.
On Sun, Jul 14, 2019, at 11:03 PM, Bron Gondwana wrote:
And this is even more exciting and I'd love to know the version!Bron.On Fri, Jul 12, 2019, at 23:33, Egoitz Aurrekoetxea wrote:By the way I think I found some more…..When a sync_client in user mode… creates a non existing user in the replica… if the user has a dot… the quota gets properly created, but seen, sub files are wrongly created… for instance….-rw------- 1 cyrus cyrus 2576528 Jul 12 13:03 f.veiga.conversations-rw------- 1 cyrus cyrus 88 Jul 12 13:03 f.veiga.counters-rw------- 1 cyrus cyrus 451 Jul 12 10:43 f.veiga.sub-rw------- 1 cyrus cyrus 16 Jul 12 01:32 f.veiga.xapianactive-rw------- 1 cyrus cyrus 2584 Apr 3 01:48 f^veiga.seen-rw------- 1 cyrus cyrus 316 Apr 3 01:48 f^veiga.subThe Apr 3 files are from the initial sync when the box was empty… the first ones (with the dot and not ^) are the actual files being used by Cyrus…. And updated with the replication and so…It seems this to be the reason because I didn’t see in the initial sync any subscribed folders… but later when set them from a mua where properly replicated…With Sieve seemed to happen something similar… but in this case with the ‘^’ and ‘.’ In the directory name….It’s like the name used for creating the subscribing and seen databases in a user mode replication was not properly handled by Cyrus… because it does the same as with quota database with indeed with ‘^’ is properly created….Thanks! Bye!Egoitz AurrekoetxeaDpto. de sistemas944 209 470Parque Tecnológico. Edificio 10348170 Zamudio (Bizkaia)Antes de imprimir este correo electrónico piense si es necesario hacerlo.El 10 jul 2019, a las 11:39, Egoitz Aurrekoetxea <egoitz@xxxxxxxxxx> escribió:Hi!It happens with any folder… in fact Trash is not the folder we would announce in special-use as Trash… it’s just a normal folder really here…. It’s a generally happening thing with rename of folders inside the own hierarchy inside the own user… (don’t really know if a rename mailbox for changing partition would have the same issue). Not something related to the Trash folder...Cheers!Egoitz AurrekoetxeaDpto. de sistemas944 209 470Parque Tecnológico. Edificio 10348170 Zamudio (Bizkaia)Antes de imprimir este correo electrónico piense si es necesario hacerlo.El 10 jul 2019, a las 11:34, Sebastian Hagedorn <Hagedorn@xxxxxxxxxxxx> escribió:Hi,I'm curious if this only happens for rename to trash, or for all renamesof subscribed folders. IMHO it makes no sense to automatically subscribeto a folder in the trash. So perhaps the bug isn't in the replicationcode but rather in the handling of rename to trash?Am 10.07.19 um 11:11 Uhr schrieb Egoitz Aurrekoetxea:About the folder subscription issue, I think I got something, at least aclose approximation... When a user causes in mua a rename mailbox (arename for a folder caused by a folder move in hierarchy), after the ownrename, if folders were subscribed “should” (for the "plain user" atleast) become subscribed in the new path. It seems that after a userrename in Cyrus the new folder is automatically subscribed (even if nosubscribe command is sent by the mua). But this, does not cause in thereplica (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 thinkthis is what I’m suffering. Obviously, if after a rename the mua sends asubscribe too, no issue is seen. I think the problem happens when amailbox rename happens and a SUB is not send later.An example :<http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANGis moved (renamed) to trash.May 16 16:16:50 mx6c imap[83976]: conversations_rename_folder: renamed<http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANGMay 16 16:16:50 mx6c imap[83976]: Rename: domain.com<http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANGMay 16 16:16:50 mx6c imap[83976]: Deleted mailbox domain.com<http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANGIn the master (sync), the folder in Trash is subscribed but in the slaveit is not, and remains subscribed the folder in the original location inthe “____.sub” file.A diff between the master (replication client) .sub file and the slave’sone is (mx5 is the master, the client and 6 the slave):--- subscripciones-mx5c/parta.partb.sub2019-07-10 08:47:29.000000000 +0200+++ subscripciones-mx6c/parta.partb.sub2019-07-10 08:48:08.000000000 +0200<http://domain.com>!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANGPerhaps a move_subscription to one or sync_apply_changesub should beforced in order to fix it?. I have seen issues with Outlook 2016 andThunderbird… both mua… perhaps by RFC they should send the SUB commandbut… it’s the only theory I could arrive to… I have a ton more caseslike this one.. Data gets properly handled but subscriptions have thisissue (perhaps we could say is a mua issue but….)..<0x197B06994D105B45.asc><Hagedorn.vcf>----To Unsubscribe:----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 Gondwanabrong@xxxxxxxxxxx----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
