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….)..
Attachment:
0x197B06994D105B45.asc
Description: application/pgp-keys
begin:vcard fn:Sebastian Hagedorn n:Hagedorn;Sebastian org;quoted-printable:Universit=C3=A4t zu K=C3=B6ln, RRZK;Netzinfrastruktur adr;quoted-printable;dom:;;Weyertal 121;K=C3=B6ln;;50931 email;internet:Hagedorn@xxxxxxxxxxxx title:M.A. tel;work:+4922147089578 x-mozilla-html:FALSE url:https://rrzk.uni-koeln.de version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
---- 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
