reconstruct changes

[Brian Awood]

On Wednesday 20 May 2009 @ 19:28, Bron Gondwana wrote:
>
> I approve of all these ideas.

Great!

> > +    while ((opt = getopt(argc, argv, "C:kp:rmfsxgGwe")) != EOF)
> > {
> >
> > +    if( config_getenum(IMAPOPT_EXPUNGE_MODE) ==
> > +	    IMAP_ENUM_EXPUNGE_MODE_DELAYED ) {
> > +	keepflag = 1;
> > +    }
>
> The only downside here is that there's no way to say "don't keep
> expunged messages" short of using a different config file.  Maybe
> add '-K' to mean "don't keep expunged"?  Messy, I know.

We thought about that, but we couldn't think of a reason why you would 
want to throw out the expunged mail prematurely.  And if you really 
want to do that, using another config file or cyr_expire is a little 
cumbersome but would effectively be the sysadmin equivalent to 
asking "do you really want to delete all those files?"

> > +    if( !warn_only ) {
>
> (in various places) - the only downside I see here is that later
> check may assume earlier "create missing stuff" ran - so you'll
> get errors looking at things inside a mailbox because you just
> can't open it without a cyrus.header file, and you chose not to
> create that.

Yes, one case where this can be a problem is if you run with -f and a 
new mailbox is found.  It doesn't get added to the mboxlist, but then 
tries to reconstruct the new mailbox.  The idea behind -w is that it 
warns about changes that would likely be user visible, so if an admin 
isn't expecting anything other than a rebuild of the cache file, they 
can be sure that is all that will happen.  This will become 
especially important for us in the near future, since we are working 
on rolling out a user self-service "unexpunge" webapp and people will 
expect to be able to get back expunged mail for the past 10 days!

> I don't have an easy answer for you though!
>
> I've added some patches (I think they're all upstream now) to
> syslog if reconstruct finds anything to fix, and also syslog
> when it gets run on any particular mailbox (to make tracking
> down changes easier), and I suspect a few more syslog
> statements in there wouldn't go astray either.  But your patch
> looks good as-is.
>
> Bron.

Better logging is always welcome!  If anyone else has questions or 
comments I'll be glad to read them, I can also submit it in bugzilla 
if it seems acceptable for a future release.

Brian