On Tue, Jun 01, 2004 at 01:31:09PM +0900, Christian Balzer wrote:
Oh yes, sorry. I now think "Maildir" exclusively, and forget that some people still use mbox :-)
Converting tens of thousands of users (in a fast and transparent as possible fashion) is no easy feat.
It's not hard in principle.
courier-imap has a feature called "loginexec" (actually something I wrote and managed to persuade Sam to include).
Whenever you login, if a file called "loginexec" exists within the Maildir and is executable, it is run. If it terminates with a zero exit code then it is deleted.
So in your case, within each Maildir you put a small loginexec script which performs the conversion from mbox to Maildir. The next time this user logs in, their mail gets converted, and then the loginexec file is deleted.
What I was using loginexec for was to transfer mail from a remote POP3 server; I wrote a small C program which pulled mail from the old server (given the hostname, username and password) and dropped it into the local Maildir. I've successfully migrated hundreds of thousands of mailboxes in this way, where I don't even have shell access to the old POP3 server.
Note though that maildir still leaves you vulnerable to some extent with large individual mails (we allow for 10MB per message max here).
Sorry, I don't follow. There's no need for the pop3/imap server to *read* every message each time a user logs in. The size for LIST can be cached, so you'd only actually open the file when the client requests the message content or headers.
The atomic tmp -> new move prevents of course the case of multiple (inbound, SMTP) writers. Alas following a recent conversation in this ML with Timo all that saves your butt and mail integrity in the case when a large message being read by slow client gets deleted by another client (dovecot instance) is Saint BufferCache. ;)
I don't understand that comment either. If process A has a file open, and process B deletes it, the file remains (in its entirety) on the filesystem until process A closes it. That's not buffer caching; that's the semantics of unlink().
Regards,
Brian.