|
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
|
----
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
