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
