On 22.10.2007, at 5.46, Hal Pomeranz wrote:
Oct 21 19:36:01 postoffice1 dovecot: POP3(someuser): file mbox- sync.c: line 1433 (mbox_sync_handle_eof_updates): assertion failed: (file_size >= sync_ctx->expunged_space + trailer_size)
Does the file have CRLFs as linefeeds instead of plain LFs? CRLF handling is probably still a bit buggy.
If that's not the problem then I'm not really sure.. It's difficult to do anything about this unless I can reproduce the problem. I've been using mboxes for my own mails fine for years. So if you can figure out a way to easily reproduce this, I'd like to know.
If this happens every time for a specific mbox, could you put it through http://dovecot.org/tools/mbox-anonymize.pl and then send the output to me and also the mailbox's dovecot.index and dovecot.index.log files?
The real problem with this behavior is that sometimes, but not in all cases, the process will leave behind a dotlock when it exits. If the abandoned dotlock is on the user's inbox, then procmail won't delivernew mail to the user until the lock is cleared. This is a big problem.
Dovecot writes the process's PID to the dotlock file. Procmail would be able to check if the PID still exists and override the dotlock immediately if it does. But since it doesn't do this, I guess you'd have to modify its sources or create some wrapper script to delete stale dotlocks.
PGP.sig
Description: This is a digitally signed message part
