search for: sync_stamp

...unt = 31, recent_messages_count = 0, seen_messages_count = 9, deleted_messages_count = 0, first_recent_uid_lowwater = 0, first_unseen_uid_lowwater = 0, first_deleted_uid_lowwater = 240, log_file_seq = 1, log_file_int_offset = 24240, log_file_ext_offset = 24240, sync_size = 13022941, sync_stamp = 1126108845, day_stamp = 1126065600, day_first_uid = {231, 205, 192, 192, 192, 158, 158, 158}}, log_file_seq = 1, log_file_offset = 24240, log_syncs = 0x0, transactions = 0, lock_id = 314, inconsistent = 0, syncing = 0} (gdb) print (*view->trans_view) $5 = {refcount = 1, methods = {clos...

...cent_messages_count = 582656, seen_messages_count = 0, deleted_messages_count = 771220, first_recent_uid_lowwater = 4290769872, first_unseen_uid_lowwater = 366928, first_deleted_uid_lowwater = 771168, log_file_seq = 0, log_file_int_offset = 0, log_file_ext_offset = 0, sync_size = 4, sync_stamp = 1, day_stamp = 0, day_first_uid = {0, 0, 753608, 4290770460, 753608, 771112, 4290770460, 0}}, log_file_seq = 777360, log_file_offset = 1799591297024, log_syncs = { buffer = 0x0, element_size = 4290770300}, transactions = -4197008, lock_id = 0, inconsistent = 0, syncing = 0, broken_c...

...t_messages_count = 0, seen_messages_count = 1452, deleted_messages_count = 0, first_recent_uid_lowwater = 0, first_unseen_uid_lowwater = 1149, first_deleted_uid_lowwater = 0, log_file_seq = 16, log_file_int_offset = 22028, log_file_ext_offset = 22028, sync_size = 101978714, sync_stamp = 1134159156, day_stamp = 1134277200, day_first_uid = {4781, 4779, 4779, 0, 0, 0, 0, 0}}, log_file_seq = 16, log_file_offset = 22028, log_syncs = 0x0, transactions = 1, lock_id = 0, inconsistent = 0, syncing = 0} (gdb) p *t $3 = {refcount = 1, view = 0x80e3668, appends = {buffer = 0x80...

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,

...t_uid = 0, messages_count = 0, unused_old_recent_messages_count = 0, seen_messages_count = 0, deleted_messages_count = 0, first_recent_uid = 0, first_unseen_uid_lowwater = 0, first_deleted_uid_lowwater = 0, log_file_seq = 0, log_file_tail_offset = 0, log_file_head_offset = 0, sync_size = 0, sync_stamp = 0, day_stamp = 0, day_first_uid = {0, 0, 0, 0, 0, 0, 0, 0}}, hdr = 0x97f1300, header = 0x9800878, from_line = 0x9800858, base_uid_validity = 1, base_uid_last = 2, base_uid_last_offset = 0, mails = {arr = {buffer = 0x97f8c40, element_size = 52}, v = 0x97f8c40, v_modifiable = 0x97f8c40},...

...ount = 8, seen_messages_count = 0, deleted_messages_count = 1248509898, first_recent_uid = 0, first_unseen_uid_lowwater = 1248509898, first_deleted_uid_lowwater = 0, log_file_seq = 1248509898, log_file_tail_offset = 0, log_file_head_offset = 6334852, sync_size = 13806612332261933056, sync_stamp = 155806360, day_stamp = 3214602280, day_first_uid = {135194511, 155806360, 155812344, 3214602456, 134786544, 3214602436, 0, 0}} rec = <value optimized out> seq = 1 seq2 = 2 uid = 216 prev_uid = 216 uflags = MAILDIR_UIDLIST_REC_FLAG_RECENT filename = 0x94c96a0 "1248509847.M93...

...unt = 8, seen_messages_count = 0, deleted_messages_count = 1245502813, first_recent_uid = 0, first_unseen_uid_lowwater = 1245502813, first_deleted_uid_lowwater = 0, log_file_seq = 1245502813, log_file_tail_offset = 0, log_file_head_offset = 12386328, sync_size = 13828297038023884800, sync_stamp = 155303216, day_stamp = 3219651144, day_first_uid = {135197247, 155303216, 155306120, 3219651320, 134735536, 3219651300, 0, 0}} rec = <value optimized out> seq = 1 seq2 = 3 uid = 70 prev_uid = 70 uflags = MAILDIR_UIDLIST_REC_FLAG_RECENT filename = 0x943a7f8 "1245502772.M1970...

...recent_messages_count = 0, seen_messages_count = 810, deleted_messages_count = 0, first_recent_uid_lowwater = 0, first_unseen_uid_lowwater = 1149, first_deleted_uid_lowwater = 2846, log_file_seq = 8, log_file_int_offset = 27912, log_file_ext_offset = 27912, sync_size = 9241460, sync_stamp = 1113863658, day_stamp = 1121659200, day_first_uid = {2855, 2849, 2849, 2753, 2753, 2753, 2491, 187}}, hdr_base = 0x80c60b0, records = 0x80c61d8, records_count = 929, extension_pool = 0x80ce490, extensions = { buffer = 0x80ce4c0, element_size = 28}, ext_id_map = {buffer = 0x80c...

...ges_count = 576, seen_messages_count = 3221216296, deleted_messages_count = 3085530619, first_recent_uid = 3085747040, first_unseen_uid_lowwater = 0, first_deleted_uid_lowwater = 0, log_file_seq = 576, log_file_tail_offset = 28, log_file_head_offset = 1, sync_size = 13256344077235912704, sync_stamp = 3085747040, day_stamp = 134956776, day_first_uid = {3221216328, 3085530784, 3085747040, 3085781192, 3086502160, 3085743644, 4294967295, 3086618612}} rec = <value optimized out> seq = 0 seq2 = 0 uid = 29 prev_uid = 29 uflags = 0 filename = 0x80aee58 "1270283027.M108835P273...

We upgraded from Dovecot 1.0.15 to 1.2.5 last night, on Solaris 10 using mboxes, mostly without issues. However I had to trash the index/cache files (too many folders were showing corruption issues which is especially bad for Prayer Webmail ".prayer" folders that store preferences; Prayer sees a disconnection as the folder being missing!). I've had one imap process panic in mailbox