On Sat, 2004-05-22 at 05:30, Christian Balzer wrote:
So, currently Dovecot doesn't try to lock mbox for the whole POP3 session. That may create problems if two sessions actually try to access the mailbox concurrently. If message gets expunged by another process, Dovecot replies with -ERR to requests to fetch the message. That might confuse some POP3 clients, or cause them to send errors to user.
That is (for me at least) acceptable as long as there is no danger of actual mailbox corruption (a message gets deleted while another client is actually downloading it). Is this the case in .99.10.4?
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.
Anyway, I have thought before that Dovecot/pop3 should lock the mbox for the whole time, just like all others POP3 servers do (and RFC says too).. I'll add in TODO.
If the RFC requires it, there will be no argument from me, though more granular locks which prevent really bad things from happening are sufficient for me and as detailed above might be more responsive.
Also you are saying mbox up there, would a maildir storage accessed via POP3 really be immune to these possibly confusing effects for clients?
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.