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 deliver new 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.