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.
