[Dovecot] Re: 0.99.10.5 release candidate

[Brian Candler]

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.