Folder subscription issue

[Egoitz Aurrekoetxea]

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)
egoitz at 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 <Hagedorn at 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190710/c315ab87/attachment.html>