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.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! > > > 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 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! >> >> >> 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 10 jul 2019, a las 11:34, Sebastian Hagedorn <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>!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. >>>> >>>> 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/ >> 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
