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