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.sub The 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 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 10 jul 2019, a las 11:39, Egoitz Aurrekoetxea <ego...@sarenet.es> 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 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 10 jul 2019, a las 11:34, Sebastian Hagedorn <haged...@uni-koeln.de >> <mailto:haged...@uni-koeln.de>> escribió: >> >> Hi, >> >> I'm curious if this only happens for rename to trash, or for all renames >> of subscribed folders. IMHO it makes no sense to automatically subscribe >> to a folder in the trash. So perhaps the bug isn't in the replication >> code 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 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. >>> >>> An example : >>> >>> The folder domain.com <http://domain.com/> >>> <http://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/> >>> <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. >>> >>> 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.sub2019-07-10 08:47:29.000000000 +0200 >>> +++ subscripciones-mx6c/parta.partb.sub2019-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….).. >> <0x197B06994D105B45.asc><Hagedorn.vcf> > > ---- > 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