reconstruct: Authoritative ACL?

[Torsten Schlabach]

Hi!

 > but then our "FixUser" tool resets the ACLs just after
 > reconstructing the mailboxes anyway

Where's that? I am not aware of this utility. What does it do? Just give 
the mailbox owner the default ACLs back?

 > hand copy a cyrus.header from the wrong directory in (in which case
 > the UniqueId is broken anyway

No, I wouldn't do that. But I might have restored mailboxes from server 
A onto server B. In that case I would assume that I can rely on UniqueId 
to be random enought to make a conflict *very* unlikely, can't I?

BTW: I think, a reason why people sometimes copy cyrus.header files 
around is that this is what makes a folder recognized as such by 
reconstruct at all. Why does reconstruct ignore a folder with messages 
in it but no cyrus.* files?

 > It's annoying that we're losing seen state.

Are you mixing subjects here? You can restore seen state (as well as 
subscriptions) if you saved the xxx.seen file (and xxx.sub file) and as 
long as the UniqueId still match.

You are loosing flags (replied, forwarded, ...), though, as they are in 
cyrus.index, aren't they?

 > Now, there's restoring from backups.  I still use reconstruct for that
 > at the moment because I can't be arsed building a full index file
 > reconstruction toolkit.  But I'll probably fix that one day.

If you are restoring from backups, why don't you have a cyrus.index file?

Regards,
Torsten

Bron Gondwana schrieb:
> On Fri, Feb 27, 2009 at 12:18:00PM +0100, Torsten Schlabach wrote:
>> Hi!
>>
>>  >> I can imagine situations where this is not what you want.
>>  >
>>  > I can't.  Please share a couple.
>>
>> If they are currupted for whatever reason?
>  
> 50/50 chance that one or the other is corrupted, of course.  Assuming
> that you haven't done anything clever like hand copy a cyrus.header
> from the wrong directory in (in which case the UniqueId is broken
> anyway, so all bets are off)
> 
> (and assuming the corruption didn't bother the magic at the start of 
> the file, without which reconstruct will ignore it)
> 
>> I mean, by the books, reconstruct is a utility which you should not 
>> need, because if nothing ever goes wrong, you will never have a need to 
>> reconstruct mailboxes.
> 
> Yeah, pretty much - which is why you'll see some diffs in the current
> CVS where I've put in logging options to let you know if they found
> anything that needed fixing...
> 
>> Also if I follow the subject recently discussed in a thread here, which 
>> basically says: "Hands off the files, if you need to move things around, 
>> do it through IMAP" you could argue that you shouldn't need the -f 
>> switch as well.
> 
> Strictly it's "if you don't understand what's going on really very
> quite well, you'll just make yourself more hurt.  Here's the way
> that actually keeps things sane".
> 
> Now, there's restoring from backups.  I still use reconstruct for that
> at the moment because I can't be arsed building a full index file
> reconstruction toolkit.  But I'll probably fix that one day.  It's
> annoying that we're losing seen state.  Though seen state sucks.
> Seen state for the OWNER of the mailbox should be stored in the
> cyrus.index file anyway - it's the 99.9999% case.  Worth optimising.
> Bloody seen files.  </rant>
> 
>> Would it hurt to have a finer grain control of how reconstruct works?
> 
> No, probably not.  We're just jumping on your "can imagine situations"
> which basically boils down to "I've munted my files".
> 
> Bron ( but then our "FixUser" tool resets the ACLs just after
>        reconstructing the mailboxes anyway, so I wouldn't notice
>        either way )