similar to: Indexes again

I just had to write this even while it's not just yet in CVS, but it's only a few fixes away from being committed.. My year long dream has finally came true :) [Summary: Next release will have REALLY kickass indexes] Previously the biggest problem with caching message data in indexes was that we had to do it while syncing the mailbox, before client even saw those messages. This caused

Although Dovecot is already read-lockless and it uses only short- lived write locks, it's be really nice to just get rid of the locking completely. :) I just figured out that O_APPEND is pretty great. If the operating system updates seek position after writing to a file opened with O_APPEND, writes to Dovecot's transaction log file can be made lockless. I see that this works with

Hi everyone: I am seeing a whole LOT of these messages in my dovecot logfile: imap(rickt): Sep 12 17:14:03 Warning: Error in custom flags file / home/rickt/mail/.imap/TRASH/.customflags: Duplicated ID 0 imap(rickt): Sep 12 17:14:03 Warning: Error in custom flags file / home/rickt/mail/.imap/TRASH/.customflags: Duplicated ID 1 and also these: imap(mbwnews): Sep 12 17:10:16 Error: Corrupted

Hello Timo, I'm having a problem with mbox that opening folder is slow when new mails are delivered to a folder. I'm delivering through the deliver program. Deliver updates index files but IHMO not completely correct. Therefore I compared index files before and after: 1.) Just delivered 2.) After accessing through imap via Thunderbird diff looks like (stripped down to the relevant

Hi, My apologies if this has been mentioned before, I haven't pulled up a google search yet. I run Dovecot from the package under OpenBSD 3.6 (dovecot-0.99.10.8). The problem I have is that occasionally dovecot corrupts an index file (I think), which causes the process to gradually creep up in usage, until it hits 99%, where it stays, without quitting. If I then fire up my mail client

I've been doing some thinking on a new better mailbox format that'd be faster than mbox and maildir for most common uses. Comments welcome. It won't come to Dovecot v1.0, but I'll probably create another branch to Dovecot CVS where I'll start implementing it and some other possibly destabilizing changes. Generic ------- The point is to have a mailbox format where the mailbox

Hi, I'm using version 0.99.10.8 on debian 2.4.26 and am getting this problem, can someone please shed some light over this? Aug 31 13:58:58 xxx imap(someone): file_wait_lock() failed with modify log file /var/mail/someone_new/Maildir/.INBOX/.imap.index.log: Resource temporarily unavailable and then: Aug 31 14:00:58 xxx imap(someone): Couldn't lock modify log file

I see these errors more often than I'd like from Dovecot-1.1.2 on Mac OS X 10.5.4 (names and numbers elided): Corrupted index cache file %s: Corrupted virtual size for uid=%d: %d ! = %d Corrupted index cache file %s: Broken virtual size for mail UID %d Corrupted index cache file %s: used_file_size too large How bad are these? What should I look for to find out why they happen? Other

Hi, I'm using Dovecot (dovecot-0.99.10p0) on OpenBSD-3.4 for few weeks now. When i connect to my IMAP account the connection is often closed by dovecot when i try to delete mails. I can see messages like this in log: Feb 29 18:47:00 po imap(mat at reynerie.org): Corrupted binary tree file /home/mat/Maildir//.INBOX/.imap.index.tree: used_file_size larger than real file size (1772 vs 1556)

Hi. Just got this error (1.1.rc4), is it something to worry about? Corrupted index cache file /.../Maildir/.Sent/dovecot.index.cache: used_file_size too large This is a shared mailbox with concurrent access. In general, can that usage pattern mess up the index? I am guessing "no", which is why I worry slightly about the warning. Cheers, Anders.

Every now and then I get an alert like this one. I have no clue what this "rear" subsystem is, or why madam would be trying to write to its log file. Can anyone enlighten me? thanks in advance! ------------------------- SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-fcshome.log.lockless. ***** Plugin restorecon (93.9 confidence) suggests

Hi- Still getting a bunch of these: Apr 30 13:45:23 mercury mem[11056]: pop3(user1): Corrupted index file /users/78/user1/Maildir/.INBOX/.imap.index: used_file_size larger than real file size (4032 vs 1608) and the occasional: Apr 30 13:08:53 mercury mem[13507]: pop3(user2): Corrupted index file (in-memory index for /users/e0/user2/Maildir): Filename mismatch for UID 1:

http://dovecot.procontrol.fi/test/ I think I've fixed the problems that were corrupting indexes with the new code. It happened every time you had expunged some messages and new messages arrived. I think this release might actually work :) disable_plaintext_auth = yes will be default from now on. It allows plaintext authentication from localhost (127.*, ::1) however. I just figured out

Hi! I'm getting these frequently. several times I've done the steps listed there to suppress the messages, but I keep getting them. Anyone got a good idea how to deal with this? Thanks in advance! ---------------------------- SELinux is preventing mdadm from 'read, open' accesses on the file /var/log/rear/rear-fcshome.log.lockless. ***** Plugin restorecon (99.5 confidence)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Suddenly since this afternoon the following happens: Sep 14 18:16:55 UnseenUniversity pop3-login: Login: gunter [127.0.0.1] Sep 14 18:16:55 UnseenUniversity pop3(gunter): Corrupted index data file / home/gunter/Mail/.imap/INBOX/.imap.index.data: Field 1 size points outside file (205408 / 205376) for record 4662 Sep 14 18:16:55 UnseenUniversity

Hello, Ferret created a 4.5GB> index file. $ 4534029210 2007-02-26 12:46 _el.cfs The creation of the index went smoothly. Searching through this index also works fine. However whenever I try to get the contents of an indexed document I get an error when the document number is above 621108: irb(main):080:0> searcher[621108].load IOError: IO Error occured at <except.c>:79 in xraise

http://dovecot.org/test/ Pretty much the only change since test24 is a redesign of how cache file writing works. Reading works as before - without locks. Before (in 1.0-tests, 0.99 was worse) we used to just try to lock it. If it failed, we just didn't update cache. If it didn't fail, the lock could have been kept a long time. For example if a user was downloading a 10MB mail, the

Hi. Dovecot 2.2, with the zlib plugin, I think we're getting bad index entries on IMAP COPY. On copying a message to an empty folder, in the dovecot error log I see: Sep 19 20:34:25 imap01 dovecot: imap(grain at rp-auth-test.com): Error: Cached message size smaller than expected (615 < 971) Sep 19 20:34:25 imap01 dovecot: imap(grain at rp-auth-test.com): Error: Corrupted index cache file

I've been seeing lots of index cache file errors (using mbox on Solaris 8 sparc 64-bit, but with 32-bit Dovecot) since I switched my account to Dovecot 1.2.0 (we're still on 1.0.15 mostly, but I'm hoping to upgrade to 1.1.17+ this summer, or 1.2.x if it's stable enough). e.g. Error: Corrupted index cache file <path>/.imap/INBOX/dovecot.index.cache: field index too large (47

On 04. mars 2018 03:03, Fred Smith wrote: > Every now and then I get an alert like this one. I have no clue what this > "rear" subsystem is, or why madam would be trying to write to its log > file. ReaR is Relax-and-Recover tool: http://relax-and-recover.org/ It creates a bootable CD/DVD with all backup content to restore your system. > If you want to fix the label. >