Corrupted index cache file error in dovecot.index.cache

Corrupted index cache file error in dovecot.index.cache

Dovecot stores per-mailbox index files including dovecot.index.cache to accelerate IMAP operations. The cache is expendable and rebuilt from message data on demand. A documented failure condition is logged when the index/mail-cache code detects inconsistent records in the cache file. Corruption is commonly associated with unclean shutdowns, storage issues and write failures, with higher risk on network filesystems.

Dovecot performs automatic detection for many index inconsistencies, and the cache can be discarded and regenerated without mail data loss. The operational uncertainty is when automatic self-healing is sufficient versus when proactive intervention is warranted, especially as behavior varies with storage backend and locking configuration.

What criteria distinguish transient cache corruption that can be left to automatic rebuild from a pattern that requires moving indexes off shared storage? Is there a documented threshold for frequency or mailbox scope that should trigger manual resynchronization? How should an operator decide between relying on automatic recovery and enforcing a consistent index location policy?