Ok, but we must lock the mailbox because we often move groups of mailbox from a file system to another. While the mailboxes are being moved, our LDA shouldn't delivery a new message at the old mailbox, and isn't able to delivery at the new one. The mailbox is unlocked after the exchange of the file system , if the dovecot locks the index files and then the mailbox exchanges of file system, what will unlock the index files of the dovecot? The dovecot process that perform the lock, will unlock the old index files. This old index files will be erased as well as the whole old mailbox, the new mailbox, that was moved to an another file system, will remains locked.

We have almost 10M of mailboxes, if the chance that it happens is something like 1/1M, it will happens 10 times per day!

mouss wrote:

Thiago Monaco Papageorgiou wrote:

...

Hello!

I need to use my lock method into the dovecot to block a mailbox. I am using maildir format, is there an API that I can implement? I need it because there are others systems which already use my lock method.

why would you lock in a maildir? maildir was designed to avoid locks. do you have an external app that "plays" with mail files? in a maildir, it may be as easy as:

# mkdir mydir # mv cur/$filename mydir/ # do what you want in mydir/

Esta mensagem foi verificada pelo E-mail Protegido Terra. Atualizado em 31/12/1969

-- Thiago Monaco Papageorgiou thiago.monaco@corp.terra.com.br

Terra Networks Brasil S/A Tel: +55 (51) 3284-4274

On Thu, 2008-08-28 at 18:43 -0300, Thiago Monaco Papageorgiou wrote:

Ok, but we must lock the mailbox because we often move groups of mailbox from a file system to another. While the mailboxes are being moved, our LDA shouldn't delivery a new message at the old mailbox, and isn't able to delivery at the new one. The mailbox is unlocked after the exchange of the file system , if the dovecot locks the index files and then the mailbox exchanges of file system, what will unlock the index files of the dovecot? The dovecot process that perform the lock, will unlock the old index files. This old index files will be erased as well as the whole old mailbox, the new mailbox, that was moved to an another file system, will remains locked.

We have almost 10M of mailboxes, if the chance that it happens is something like 1/1M, it will happens 10 times per day!

I guess the main problem is that you need to lock user's all mailboxes instead of just one. A single mailbox can be easily locked using v1.1.2's new maildirlock utility, but I don't think this will help you, at least not reliably.

I've actually a related item in my TODO list:

• convert plugin: Create a r/w lock for a file. It's read-locked if conversion isn't wanted and released when process dies. If conversion is wanted and write-lock succeeds, conversion is done, if write-lock doesn't succeed it fallbacks to using the old storage. When process is exiting it again tries to write-lock and do the conversion. Add a parameter that specifies if conversion should be done.

So the idea would be that both the deliver and imap/pop3 would load the convert plugin and use that user-global lock file for figuring out when it's safe to do the conversion. With IMAP processes perhaps it should try the conversion also while the process is running, otherwise for long-running connections it could take a long time to get the mailbox converted.