search for: used_file_size

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.

...ckt/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 index file /home/ mbwnews/mail/.imap/INBOX/.imap.index: used_file_size larger than real file size (2016 vs 1608) imap(mbwnews): Sep 12 17:10:18 Error: Corrupted index file /home/ mbwnews/mail/.imap/INBOX/.imap.index: used_file_size larger than real file size (2016 vs 1608) And not just referring to my inbox, other users as well. I hava bog standard install of...

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 details: File system is HFS+ Mail store is maildir Hardware is Intel (Mac Pro) Thanks.

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

...Resource temporarily unavailable and then: Aug 31 14:00:58 xxx imap(someone): Couldn't lock modify log file /var/mail/someone_new/Maildir/.INBOX/.imap.index.log and finally: Aug 31 14:26:35 xxx imap(someone): Corrupted modify log file /var/mail/someone_new/Maildir/.INBOX/.imap.index.log: used_file_size larger than real file size (4096 vs 2576) MTA is qmail 1.03 (with procmail v3.22) TIA, Fredrick -- Systemadministration EsPresto AG ----------------------------------------------------------------- backman at espresto.com Breite Str....

...t this always when checking mail for the first time, cheking mail for the second time tells me: Sep 14 18:18:43 UnseenUniversity pop3-login: Login: gunter [127.0.0.1] Sep 14 18:18:43 UnseenUniversity pop3(gunter): Corrupted binary tree file / home/gunter/Mail/.imap/INBOX/.imap.index.tree: Invalid used_file_size in header (0) but actually fetches the mail after that. So what can/should I do? Simply delete the offending index file? The dovecot version I'm using here is Debian's ii dovecot-pop3d 0.99.10-7 A secure POP3 server that supports mbox and and only it's pop3 part. Greetings,...

...e tail offset ..... = 16828 +log file head offset ..... = 16828 - - sync_mtime . = 2012-08-30 19:38:05 + - sync_mtime . = 2012-08-30 20:09:23 - - dirty_flag . = 1 + - dirty_flag . = 0 - - highest_modseq = 11162 + - highest_modseq = 11163 - - log_offset ... = 16468 + - log_offset ... = 16828 CACHE: -used_file_size ....... = 6385696 +used_file_size ....... = 6392132 RECORD: seq=25663, uid=25835, flags=0x00 - - ext 0 keywords : (0000) - - ext 1 modseq : 11156 (942b000000000000) + - ext 0 keywords : (0100) + - ext 1 modseq : 11163 (9b2b000000000000) - ext 2 mbox...

...p0) 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) I tried to remove all index files, but the problem still occur. I also tried Maildir and Mbox, same problem (i can't remember if the log are similar with mbox, if needed i will test again). I have ktraced the imap process and try (succesfully) to rep...

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: 1051720748.28556.mercury.mv.net vs 1051715695.29601.mercury.mv.net Most of the time (but...

...This of course requires twice the amount of space for dataset plus one extra bit, so it shouldn't be used too much - If data can be only set, but never changed, we need only one extra bit to specify if the data is set. - Appending new data to end of file. We'd have to have used_file_size variable in header, done like described above. - Each cached message record would have a pointer to next part, so more cached data could be appended to file. Message flags are the most commonly modified data. If we just modify them directly, a simultaneous read might catch the change only p...

...est version? Some example errors from my logfile: imap(gaby): Apr 11 15:32:37 Error: Corrupted index file /home/gaby/Maildir/.INBOX/.imap.index: Wrong messages_count in header (261 != 382) imap(gaby): Apr 11 15:32:37 Error: Corrupted index data file /home/gaby/Maildir/.INBOX/.imap.index.data: used_file_size larger than real file size (142368 vs 10264) imap(gaby): Apr 11 15:32:44 Error: Corrupted index file (in-memory index for /home/gaby/Maildir): UIDVALIDITY changed in uidlist imap(gaby): Apr 11 15:36:12 Error: Timeout while waiting for release of shared fcntl() lock for index file /home/gaby/M...

...buffer gets full (and so we don't need a huge buffer). Once transaction completes, we lock the cache again and try to free the extra reserved space we have left. If multiple processes weren't updating the cache file at the same time, the freeing should be as simple as decreasing "used_file_size" field in header. Alternatively we'll update a linked list of "holes" in the file. When reserving space, we first try to use those holes instead of appending to end of file. Pointers to new cache records are also written to transaction log at the end of cache transaction. Th...

...epmccull): Corrupted index cache file /home/students/e/epmccull/.imap/INBOX/dovecot.index.cache: Cache record offset 1768 points outside file Oct 14 11:59:39 emerald dovecot: [ID 107833 mail.error] imap(epmccull): Corrupted index cache file /home/students/e/epmccull/.imap/INBOX/dovecot.index.cache: used_file_size too small Oct 14 11:59:39 emerald dovecot: [ID 107833 mail.error] imap(epmccull): file mbox-lock.c: line 518 (mbox_lock): assertion failed: (lock_type == F_RDLCK || mbox->mbox_lock_type != F_RDLCK) Attached is a gdb session on the core dump. Thanks. Jeff Earickson Colby College --------------...

...4/860/grain at rp-auth-test.com/.Bup//dovecot.index.cache major version ........ = 1 minor version ........ = 1 indexid .............. = 1379605150 (2013-09-19 15:39:10) file_seq ............. = 1379605174 (2013-09-19 15:39:34) (24 compressions) continued_record_count = 0 record_count ......... = 0 used_file_size (old) . = 108 deleted_record_count . = 0 field_header_offset .. = 32 (0x88808080 nontranslated) -- Cache fields -- # Name Type Size Dec Last used 0: flags bit 4 tmp 2013-09-19 20:07 1: hdr.Message-ID...

...ut = 120, stale_timeout = 60, immediate_stale_timeout = 300, callback = 0, context = 0x0}, dotlock = 0x0, hdr = 0xff100000, hdr_copy = {version = 1 '\001', unused = "\000\000", indexid = 1124149513, file_seq = 1124149515, continued_record_count = 51, hole_offset = 0, used_file_size = 81884, deleted_space = 0, field_header_offset = 2155918518}, field_pool = 0xaad88, fields = 0xabcb0, field_file_map = 0xabb58, fields_count = 26, field_name_hash = 0xab180, file_field_map = 0xab6e0, file_fields_count = 26, locked = 0, need_compress = 0, hdr_modified = 0, field_header_write_...

...callback = 0, context = 0x0, use_excl_lock = 0}, dotlock = 0x0, hdr = 0x0, hdr_copy = {version = 0 '\0', compat_sizeof_uoff_t = 0 '\0', compat_sizeof_time_t = 0 '\0', unused = 0 '\0', indexid = 0, file_seq = 0, continued_record_count = 0, hole_offset = 0, used_file_size = 0, deleted_space = 0, field_header_offset = 0}, field_pool = 0xbb7a8, fields = 0xbc188, field_file_map = 0xb9018, fields_count = 9, field_name_hash = 0xb8388, need_compress_file_seq = 0, file_field_map = 0x0, file_fields_count = 0, locked = 0, hdr_modified = 1, field_header_write_pend...

http://dovecot.org/test/ - vpopmail authentication fix - many mmap_disable=yes fixes and a few optimizations - pop3 hang fix - mbox fix for "last-uid lost" error (hopefully last one) - mbox fix for losing dirty flag, causing lost message flags mmap_disable=yes seems to be finally working pretty well. There should be no more cache file related errors with it enabled. I'm still