Cyrus 2.5 status

[Gerd v. Egidy]

> > This will make finding mailboxes in filebased backups a lot harder,
> > as we would have to restore the mailboxes.db from backup first to get
> > the uniqueid. Using softlinks (mailboxname == link name, link points
> > to the uniqid)
> > might work depending how the backup program shows links.

I second this.
 
> I would put the history of names that it had in the cyrus.header too, so it
> can be recovered.

This will only help finding the correct name when you have a folder, but not 
help finding a folder when you only got the path+name.
 
> Harder to find individual mailboxes, sure.  I don't care though.  We should
> be doing backups better, and good tooling will fix this.  The advantages of
> super fast atomic deep renames outweigh the problems.

I do not agree. 

Having a fallback to files/directory level and being able to recreate a sane 
mailbox state from there has saved me several times. In several occasions the 
mailboxes.db was broken beyond repair (cyrus bugs in ver 2.3, machine lockups, 
faulty ram without ecc,...), in other cases the filesystem was broken and only 
parts of it were readable. The customer was lazy with backups so I had to work 
with what was available.

It is also a big plus for debugging & maintenance purposes to be able to 
directly see the folders on the filesystem. E.g. doing a grep, lsof, ftop, 
ncdu,...

So please keep a way to navigate the folder structures on disk. Using symlinks 
would be the obvious choice and would introduce only marginal load when moving 
folders.

Thank you.

Kind regards,

Gerd