>>>>> "BG" == Bron Gondwana <brong@xxxxxxxxxxx> writes: BG> The advantage of reconstructing (if you choose that BG> path instead, heaps more IO use though) is that you'll get real SHA1 BG> GUIDs rather than padded GUIDs. Not a huge deal - though I'll BG> probably force the SHA1 calculation in the 2.4 upgrade, because I BG> want full integrity checking enabled! I ended up not doing a reconstruct run; I did a replication to a test server, update it to 2.3.16 and tested; everything was fine. Then I did the reconstruct: /usr/lib/cyrus-imapd/reconstruct -r -s -k "user/*" as suggested elsewhere in this thread and it ran without problems except for a few complaints about messages with over 1000 lines of header. Unfortunately, after running it, all messages in folders besides my INBOX had lost their seen state and were shown as "new" in two different clients (alpine and thunderbird). I can't quite determine if this is expected behavior. If it is, that's a significant downside. If it isn't, I wonder what's going wrong. I have altnamespace: 1 and unixhierarchysep: 1 in imapd.conf, if it matters. It looks like the seen.db was still intact but it's not as if I can actually read a skiplist file. - J< ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
