Timo wrote (hmm, given the usual programmers life style I'd say VERY late at nigth :) :
There's no possibility for corruption, as long as all software accessing mbox uses compatible locking. So if you don't have mbox_read_dotlock set, make sure everyone uses also fcntl (or flock) locking.
Oh, my worries are not about the only other bit accessing the boxes, which is exim and that uses fcntl. My question was about this, not at all theoretical scenario: User has a client at home to auto-download (but leave mails on server) and is using a slow link, so those message downloads take a quite measurable time. Now he logs into webmail (which of course also ultimately uses dovecot to access the mailbox) and deletes a message which is currently in transit to his home machine. Will the result be: a) The "read" of that message has triggered an internal dovecot lock and the "write" of the delete will have to wait until this is released. b) The delete happens immediately, but thanks to buffering the read and delivery of the message is always successfully finished. c) The delete of the message happens immediately, the state of the message in transit is indeterminable and it might be truncated.
Maildir can't be locked and so it has the same problem that message might get lost. That's pretty much the reason why I didn't bother to make pop3 lock mboxes either. Both mbox and pop3 are of smaller priority to me than maildir+imap, and making some mbox+pop3-specific locking kludge there wasn't very attractive.
Totally understood and agreed with. The solution would of course be to totally lock out any other logins (imap or pop) while a pop3 session is active, like qpopper does. Alas that would have the aforementioned unpleasant side effects. So as long as the answer to the above question is a) or b) I see no reason to add either mbox or session locking.
Regards,
Christian Balzer
Christian Balzer Network/Systems Engineer NOC chibi@gol.com Global OnLine Japan/Fusion Network Services http://www.gol.com/