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
