> > 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
