delayed delete bug?

[Bron Gondwana]

On Wed, 17 Oct 2007 09:04:33 +0200, "Rudy Gevaert" <Rudy.Gevaert at UGent.be> said:
> > b) think they should be hashed based on the username rather than into 'u'?
> 
> Keeping the same filesystem layout I would either prefer
> 
> DELETED/user/rudy.gevaert/Foo/471364C1 at ugent.be to be located in 
> /somewhere/imap/domain/u/ugent.be/DELETED/r/user/rudy^gevaert/Foo/471364C1/

That's doable, though it's a special case of sorts which brings "DELETED"
outside the standard hashing layout.

> or have it in 
> /somewhere/imap/domain/u/ugent.be/r/user/rudy^gevaert/DELETED/Foo/471364C1/

Totally bogus.  This is the same path as the legal user folder:

INBOX.DELETED.Foo.471364C1

> > c) think something entirely different should be done with them?
> 
> > My (c) is as I posted in my followup:
> > 
> >> We wrote our userhash patch so the locations would be:
> 
> I can see the advantages of this too!  How do you think about this Ken?
> (I'm not sure if this needs to be in 2.3.10 as it's a bit of a big
> change.)

Actually it's a tiny change :)  It was only a handful of lines of code and
it's protected by a config option anyway.

The downside is a rather big and messy "rehash" that's not entirely good
about cleaning up after itself - so I would recommend against inclusion
in 2.3.10 at this point.  I'd rather get a stable 2.3.10 out there than
keep holding off for it to be perfect.  Version numbers are cheap :)

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm