reconstruct should not destroy a readable cyrus.expunge.
robm at fastmail.fm
Fri Aug 11 20:23:07 EDT 2006
> Are we in agreement? Paul's patch (bug #2866) actually unexpunges the
> messages. I thought that folks we arguing that cyrus.expunge and the
> references messages should be left alone and omitted from cyrus.index.
I agree, left alone is the way to go. Really a reconstruct on a valid
mailbox should have no effect.
> that the right solution would be to leave cyrus.expunge alone, unless it
> was unreadable. If it were unreadable, the messages should be
> unexpunged. Any validation of cyrus.expunge is also welcome.
If the cyrus.unexpunge is unreadable, then it should just be removed. In
which case, we're left with the case of a mailbox with /^\d+\.$/ files that
aren't in cyrus.index. I presume a standard reconstruct run searches the
directory for stray \d+\. files that aren't in cyrus.index and re-adds them,
which is then the same as an unexpunge effectively in the case of an
unreadable cyrus.expunge file. Is that right?
>> then we will submit a patch. We're also having issues with non-unique
>> mailbox IDs. I'd like reconstruct to detect non-unique mailbox IDs and
>> assign new mailbox IDs as appropriate. Any comments on that?
> Sounds reasonable.
That would be good. The only problem is that you really want "globally"
unique id's. We've seen a couple of cases with reused uniqueid's (probably
our fault with some of the messy stuff we do at the low level), and it
really stuffs up replication. To get globally unique, you'd have to check
every cyrus.header file of every mailbox if I'm not mistaken?
More information about the Cyrus-devel