> It doesn't really matter for a seen_bigdb, because they'll be keyed by > user AND uniqueid - meaning they are no more likely to generate > clashes than they were before under seen_db.
Ah yes, good point! > Besides, they only matter within the non-user folders now. Yeah, but just because most of our folders aren't shared, doesn't mean that there aren't environments out there where most folders *are* shared. Want to make sure we're not doing something that'll be obviously dangerous in other types of uses. > More interesting is the potential for clashes during replication, > which would generate a rename event across users. That could get > super-ugly! Oooo, user renames will be a bit ugly! > But it's not a high risk - the adhoc uniqueid is a hash of the > folder name concatenated with the uidvalidity, so you'd have to have > a hash collision and creation at the same second. Restore from > backup after a rename is the disaster case. The best way to protect > against that is to move the cyrus.header data into a central DB and > scan it for matches before creating an entry. Either key an "index" > db against the uniqueid directly, or just do a full table scan. The > IMAP "LIST" command already does a full table scan, so it can't be > TOO expensive :) Do you really want another db? And "restore from backup after rename" has to be incredibly rare case, it's not worth worrying about. Rob
