Seen databases

[Robert Mueller]

> 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