MESSAGE quota resource implemention

[Bron Gondwana]

On Fri, Sep 02, 2011 at 09:37:24AM +1000, Rob Mueller wrote:
> 
> >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:
> 
> $spooldir/a/user/aardvark/user.aardvark/
> $spooldir/a/user/aardvark/user.aardvark.drafts/
> $spooldir/a/user/aardvark/user.aardvark.trash/
> $spooldir/a/user/aardvark/user.aardvark.foo/
> $spooldir/a/user/aardvark/user.aardvark.foo.bar/
> $spooldir/a/user/aardvark/user.aardvark.abc.xyz/

I still have a patch somewhere that does that.

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

It does give you a 256 character folder tree limit on many operating
systems.

> Delete handling is still easier, just rename to
> DELETED.$oldname.$UNIQUEID or something like that, because it's
> cheap to rename anyway.

Sorry, make that 239, once you make space for timestamps and dots.

> 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 come :)

tools/rehash - I have one of those that can handle this plus all the
other existing formats as well.  It's on a git branch somewhere.

Bron.