mail-index-sync-update.c revision 1dec807061d7d428dba5c5a92cd2a5ff843a2039
0N/A/* Copyright (C) 2004 Timo Sirainen */ 0N/A#
if 0
// FIXME: can we / do we want to support this? 0N/A /* previous transaction was an extension introduction. 0N/A we probably came here from mail_index_sync_ext_reset(). 0N/A if there are any more views which want to continue syncing 0N/A it needs the intro. so back up a bit more. 0N/A don't do this in case the last transaction in the log is 58N/A the extension intro, so we don't keep trying to sync it 0N/A over and over again. */ 98N/A /* we could have already updated some of the records, so make sure 98N/A that other views (in possibly other processes) will see this map's 98N/A header in a valid state. */ 0N/A /* different recent-flag */ 58N/A /* different seen-flag */ 58N/A /* different deleted-flag */ 144N/A /* call expunge handlers only when syncing index file */ 98N/A /* we don't ever want to move around data inside a memory mapped file. 98N/A it gets corrupted too easily if we crash in the middle. */ 98N/A // FIXME: it's necessary for current view code that we get atomic 98N/A // map even if these messages are already expunged, because the 0N/A // view code doesn't check that and our index_int_offset goes wrong 207N/A /* everything expunged already */ 0N/A /* lookup_uid_range() relies on this */ 0N/A "Append with UID %u, but next_uid = %u",
0N/A /* move to memory. the mapping is written when unlocking so we don't 0N/A waste time re-mmap()ing multiple times or waste space growing index 0N/A /* don't rely on buffer->used being at the correct position. 0N/A at least expunges can move it */ 0N/A "Header update outside range: %u + %u > %u",
/* the tail offset updates are intended for internal transaction log handling. we'll update the offset in the header only when /* this is simply a request for expunge */ /* should be just extra padding */ "ext intro: name_size too large");
"ext reset: invalid record size");
"ext hdr update: invalid record size");
"Extension record updated " /* the record is padded to 32bits in the transaction log */ "ext rec update: invalid record size");
/* make sure we re-read it in case it has changed */ /* do we have dirty flags anymore? */ /* see if we'd prefer to reopen the index file instead of syncing the current map from the transaction log */ /* this isn't necessary correct currently, but it should be /* can't use it. sync by re-reading index. */ /* view referenced the map. avoid unnecessary map cloning by unreferencing the map while view exists. */ /* if syncing updates the header, it updates hdr_copy_buf and updates hdr_base to hdr_copy_buf. so the buffer must initially contain a valid header or we'll break it when /* FIXME: when transaction sync lock is removed, we'll need to handle the case when a transaction is committed while mailbox is being synced ([synced transactions][new transaction][ext transaction]). this means int_offset contains [synced] and ext_offset contains /* this has been synced already. we're here only to call expunge handlers and extension update handlers. */ /* we'll just skip over broken entries */ /* update sync position */ /* transaction log tracks internally the current tail offset. besides using header updates, it also updates the offset to skip over following external transactions to avoid extra unneeded log /*FIXME:if (mail_index_map_msync(index, map) < 0) /* restore refcount before closing the view. this is necessary also if map got cloned, because view closing would otherwise destroy it */