delayed delete bug?

Bron Gondwana brong at
Mon Oct 15 17:25:57 EDT 2007

On Mon, Oct 15, 2007 at 03:25:28PM +0200, Rudy Gevaert wrote:
> Hi,
> I'm busy looking at delayed delete.  I'm using unix hierarchy seperator.  I 
> deleted a mailbox and see it like this:
>> lm
> DELETED/user/rudy.gevaert/Foo/471364C1 at (\HasNoChildren)
> user/rudy.gevaert/Inbox2 at (\HasNoChildren)
> user/rudy.gevaert/Trash2 at (\HasNoChildren)
> user/rudy.gevaert/Trash at (\HasNoChildren)
> user/rudy.gevaert at (\HasChildren)
> However the file system location is:
> /var/cyrus/imap/domain/u/^gevaert/Foo/471364C1/

Yeah, that's a "feature" - you see, hashing is done by whatever's after
the first dot.  In theory you don't have to care.

We wrote our userhash patch so the locations would be:


Which makes much more sense to me and has the nice property that a
directory is either a "trunk" or a "leaf" but not both - it contains
either purely sub directories or purely mailbox contents.

> I would have thought it would be under domain/u/
> Is something going wrong here?


> I've run cyr_expire and it cleans it up nicely!
> Also, is it correct to undelete a deleted folder I need to rename it? (This 
> works! And gets replicated).

Yeah, it all works fine.  It's just an odd location.  I got over that
pretty quickly given that my Perl libraries know where it is and Cyrus
knows where it is so I just let them do the legwork.


More information about the Cyrus-devel mailing list