Questions about user mode sync_client (move mailboxes from one server to another) and mailbox moving from partition (moving from partition in same server, renaming) lock

[Egoitz Aurrekoetxea]

Hi Sebastian, 

Thanks a lot for your comments. But that, anyway, won't assure no
mailbox access would exist in the middle of the rename... 

I think there should not be problems due that the function
mboxlist_renamemailbox() does a mailbox_open_iwl() which finally checks
if the mailbox is locked and then locks it. Anyway, if none of the gurus
of Cyrus sais it... I would read more deeply the code (for ensuring) and
will do some checks in testing env.... 

Thanks a lot Sebastian :) 

Cheers 

El 2019-05-23 19:28, Sebastian Hagedorn escribió:

> Hi,
> 
>> Our Cyrus machines (Cyrus 3.0.8), usually have 3 mailbox partitions.
>> Sometimes, one of them becomes highly filled so we usually perform a
>> mailbox rename to another partition of the same server. For that
>> purpose, we normally lock at our proxy barrier any access to the mailbox
>> (we do play with Nginx authentication, Postfix hold and so....). Is it
>> really needed to lock that way the mailbox, at some "external to Cyrus
>> level," in order to avoid mailbox corruption?. Or does Cyrus handle that
>> properly?. Does Cyrus exclusively lock and after done, unlock again?.
> 
> I can only answer that part of the question. We have been doing it like that (without blocking access from the outside) for years, but we're still on Cyrus 2.4. We only make sure there are no active processes by the user before starting the RENAME, and we do it at night. There haven't been any problems with that approach.
> --
> Sebastian Hagedorn - Weyertal 121, Zimmer 2.02
> Regionales Rechenzentrum (RRZK)
> Universität zu Köln / Cologne University - Tel. +49-221-470-89578
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190524/f0100015/attachment.html>