MESSAGE quota resource implemention
robm at fastmail.fm
Thu Sep 1 19:37:24 EDT 2011
> Actually, really I'd like to create a new UNIQUEID - and store
> all the files in paths based on uniqueid rather than on folder
> name. This would not only mean renames could be fast and
> atomic, but that delayed delete would be fast. The downside is
> a more opaque filesystem layout. Oh, another upside - file path
> limitations don't exist so much any more.
While UNIQUEID is nice, the opaqueness is annoying. Personally, I liked the
idea that we talked about a while back which I think was:
So you end up with every folder for a user in one dir. This solves the
current messy handling of sub-dirs (eg currently you have to create the
intermediate dir /abc/ even though there's no entry in mailboxes.db for it),
and makes renaming any folder very cheap still (because you can do it with a
single dir rename, rather than having to move each message file), but you
don't go completely opaque.
Delete handling is still easier, just rename to DELETED.$oldname.$UNIQUEID
or something like that, because it's cheap to rename anyway.
Of course it means re-organising folder layout for every installation out
there, but maybe we need to bump major versions anyway, cyrus 3.0 here we
More information about the Cyrus-devel