You could try 'reconstruct -R' which should force a re-parsing of
all message files in the mailboxes directory. Note that if this
works, you will have 8k new messages show up in your mailbox.
Adding -n may just report what reconstruct will do rather than
actually doing it.
On 6/4/20 6:45 AM, Brian J. Murrell
wrote:
On Wed, 2020-06-03 at 19:35 -0400, Ken Murchison wrote:Brian, Trying running 'unexpunge -l' on the mailbox in question.This avenue has already been explored earlier in this thread: https://lists.andrew.cmu.edu/pipermail/info-cyrus/2020-May/041258.html To save the effort of re-reading the message: # sudo -u cyrus bash -c "/usr/lib/cyrus-imapd/unexpunge -l user.brian" [nothing returned] So this is looking more like a "bad accounting" problem than something typically operational. But how to reconcile it? It seems to me that a process of comparing what's in the index to what's on disk to account for the orphans is needed. I just don't know what that process is. I probably just don't know the toolset well enough to know which tools to apply and how. mbexamine seems a candidate but I'm not sure how to interpret it's output to this task. Or maybe there other/better tools? Any suggestions? Cheers, b.
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
-- Kenneth Murchison Senior Software Developer Fastmail US LLC
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
