similar to: (mail_index_sync_update_index): assertion failed

Hello, I am running Dovecot 1.0.5 and seem to have lots of errors in my Dovecot logs. The worst errors are things like: Oct 30 16:11:42 delta2 dovecot: IMAP(x): Corrupted transaction log file /home/spamcop-net2/deputies/dovecot.index.log: end_offset (392) > current sync_offset (388) Oct 30 16:11:42 delta2 dovecot: IMAP(x): file mail-index-sync-update.c: line 841

Environment: Dovecot 1.0beta8 Host: 64 bit Red Hat AS4 Linux (2.6.9-34.0.1) Disks: NFS netapp In the case below, the two connections were going through two separate servers sharing disks via an NFS NetApp. Here is the sequence of operations: 1. Open a connection to a folder (say mail/Trash) 2. Open a connection to another folder (say Inbox) 3. Move messages from Inbox to Trash using this

Hi all, im doing some tests with the test56 release and im seeing some problems with APPEND (may be related to something else, I just see it with APPEND). When I ask someone to move some emails from one mailbox to another, after some messages (seemingly random), the client experiences a 'hang'. When tracing the process what seems to happen is that dovecot doesnt send a final OK after

>From today's maillog: maillog:Dec 28 09:29:40 aurora dovecot: IMAP(doug): msync() failed with index file /home/doug/Maildir/.projects.job591/dovecot.index: Invalid argument maillog:Dec 28 09:30:21 aurora dovecot: IMAP(doug): msync() failed with index file /home/doug/Maildir/dovecot.index: Invalid argument maillog:Dec 28 09:30:22 aurora dovecot: IMAP(doug): msync() failed with index file

I just noticed one instance of this in the current CVS version: dovecot: Jul 18 15:25:48 Error: 5962 IMAP(mailuser): mbox sync: Expunged message reappeared in mailbox /mailhome/new/o/h/mailuser/mbox (UID 2834 < 2872) dovecot: Jul 18 15:25:48 Error: 5962 IMAP(mailuser): file mail-index-transaction.c: line 129 (mail_index_buffer_convert_to_uids): assertion failed: (*seq != 0) dovecot: Jul

I installed test53 tonight, and I've begun to see the following error in my maillog every time I attempt to retrieve mail from an imap client: dovecot: child 46128 (imap) killed with signal 11 I built from source on FreeBSD 4.9 with the following: ./configure --with-mysql --with-storages=maildir --with-ssl=openssl A little bit of Googling seems to indicate that this is a hardware

Hi, I'm having trouble as of about noon today. I noticed I wasn't getting any new messages in Thunderbird. I restarted it and still nothing. I looked at the log, and found nothing from dovecot for a long time (since perhaps noon today). I restarted dovecot, but still it didn't get me new mail. I finally removed dovecot.* in my Maildir folder and restarted dovecot. I'm

We recently upgraded to dovecot v1.0.15 (from v1.0.0 + some local fixes), and after this upgrade we've started to get a couple of failures from deliver: Jan 12 20:34:34 smtp1.ulh.mydomain.net deliver(someuser at somedomain.net): Raw backtrace: /usr/local/dovecot/libexec/dovecot/deliver(i_syslog_panic_handler+0x1c) [0x45577c] -> /usr/local/dovecot/libexec/dovecot/deliver [0x45537c] ->

Hello. I am using dovecot-1.0-test53 with Maildir mailstore, with pine 4.61 as MUA. I have several folders which cause error messages like 'Junk in start of group' in Pine when I read them. I googled a bit for this, and found that removing the index file should do the trick, but unfortunately, it does not. What can I do to make these annoying messages disappear ? Thanks in advance.

Hi, Dovecot 2.0.13 imap process segfaults in the following scenario on Debian GNU/Linux unstable (amd64) and Solaris 10 (amd64): $ telnet localhost imap Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready. 1 login username password 1 OK [CAPABILITY IMAP4rev1

http://dovecot.org/test/ Sorry for not answering any questions for past two weeks, I'll try to get around answering them in next few days. I've also been thinking about if I should switch from CVS to Darcs. It seems to be exactly the kind of reversion control tool I had wanted to use. Anyone have comments for or against it? I'd still have read-only CVS repository generated from

When attempting to save a message from the INBOX to a folder in a collection (like, .projects.dovecot), I get behavior like this (in GDB). Any clue what might be going wrong? Here's where a SIGABRT happens: 280 return array->buffer->used / array->element_size; This is the stack trace: (gdb) where #0 mail_index_map_get_ext_idx (map=0x1200c0db0, ext_id=0,

I've seen this was mentioned before but remains unsolved. I upgraded Dovecot from 0.99 to v1.0.alpha4 yesterday and it rendered my inbox inaccessible: Dec 15 00:09:07 sand dovecot: imap(willers): Corrupted index file /home/willers/mail/.imap/INBOX/dovecot.index: messages_count too large (1121 > 1115) I've since moved that inbox away so I can view my new mail again. The error has

Hi folks! I have set up dsync replication with SSH according to http://wiki2.dovecot.org/Replication with the exception of having system users and calling doveadm dsync-server directly from authorized_keys, because the wrapper script posted on the above site is needless (at least in 2.2.10). However, while the two instances connect well to each other, no synchronisation is performed at all, the

I'm in process of moving away from Cyrus to Dovecot. I have my own authentication daemon working fine. It sets up two sockets: drwxr-x--- 2 root dovecot 512 Dec 7 21:07 /var/state/dovecot/login srw-rw-rw- 1 krot krot 0 Dec 7 21:07 /var/state/dovecot/login/sock drwx------ 2 krot wheel 512 Dec 7 21:07 /var/state/dovecot/master srw-rw-rw- 1 krot wheel 0 Dec 7 21:07

Part of our migration plan takes our users from one endianness to another (big to little). Will the index and mail cache files survive? I'm seeing some new core dumps as the first test user is migrated, which makes me think... not. What about if we want to build dovecot 64 bit in the future? Will that cause problems too? Stack trace is below the log messages. I've edited the

Hi Timo, Awhile back I'd written about making changes to some of the log levels that dovecot writes to to stop the process from writing these to monitor. I wanted to run a few changes by you for this, just to make sure these won't cause problems somewhere else. And to send this to the list, in case anyone else wants to make similar changes in the future. In the file

Hi, I have the following code: Message, belongs_to :topic, :counter_cache => true topic = Topic.find_from_permalink(params[:id]) topic.messages.create(params[:message]) When the message gets created, then AR issues a supplemental SELECT to retrieve the message''s topic and then updates its messages_count. Why is that happening? If I do it manually: if

Hi, I'm using py-rrdtool 0.2.1 with rrdtool 1.3.0 under 7.0-STABLE, and there's a couple of things about this new version of rrdtool that hurt performance under FreeBSD, but apparently help on whatever they tested on. For every update, the database file is opened, mapped into memory, madvise() is called, contents are modified, msync() is called, and the file is unmapped and closed:

http://dovecot.org/test/ Nothing big, just random fixes. - Crashfixes in keyword code - -std=gnu99 wasn't working well in all systems, configure now checks for it - FreeBSD sendfile() calling was broken sometimes. No need to remove #define HAVE_FREEBSD_SENDFILE anymore. - FETCH BODY[] wasn't setting \Seen flag. - LDAP fixes (by Kazuo Moriwaka) - Don't crash if client