Cyrus 2.4.X delete mailbox oddities

[Bron Gondwana]

On Tue, 28 Jun 2011 08:58 +0100, "David Carter" <dpc22 at cam.ac.uk> wrote:
> If I delete a mailbox selected by the current IMAP session in 2.4.X then 
> the underlying files are are only removed on logout. I suspect that this 
> is a consequence of the new mailbox code, which is fair enough.
> 
> I have however discovered two wrinkles when deleting mailboxes selected by 
> some other IMAP session. PINE might leave a mailbox selected for days.

Well, that's classy PINE.  How is it keeping the connection open?  Surely
it sees the deletion event and closes it.

> 1) Deleted mailboxes remained locked:
> =====================================
> 
> If I delete a mailbox which is selected (either in the current IMAP 
> session or some completely unrelated session) then it is not possible to 
> create a new mailbox with the same name:
> 
> C1:
>     . SELECT foo
> 
> C2:
>     . DELETE foo
>     . OK Completed
> 
>     . CREATE foo
>     . NO Mailbox is locked
> 
> until any sessions which have the old mailbox selected are shut down.

Yeah, sorry - short of forcibly killing the connection, there's not much
we can do about this without breaking the guarantees that messages are
still available.

If you really want to stop this, then setting
IMAPOPT_DISCONNECT_ON_VANISHED_MAILBOX should cause the connection to be
forcibly killed off next time pine does anything. 

> 2) Debris left on the filesystem
> ================================
> 
> If I DELETE a mailbox which is selected in a separate IMAP session:
> 
> C1:
>     . SELECT foo
> 
> C2:
>     . DELETE foo
>     . OK Completed
> 
>     . LOGOUT
> 
> C1:
>     . LOGOUT
> 
> The cyrus.* and messages files are left on disk, and overwritten in place 
> when a subsequent login session creates a mailbox with the same name.

The separate IMAP session should clean it up when it disconnects.  It's
basically "last one out turn off the lights".

> Is this deliberate?

Well - it's going to happen unfortunately if you have disconnect on
vanished mailbox, because it does a 'fatal()'.  That kind of sucks
actually.

> I suppose that the only real danger is that reconstruct might resuscitate 
> messages belonging to an earlier version of a mailbox with the same name.

reconstruct should notice that OPT_MAILBOX_DELETED is set in the cyrus.index
flags and complete the delete I think.  At least, that's how it's supposed
to work.

I would like to change the mailboxes.db format so that we keep the fact
that there's a deleted mailbox there in mailboxes.db for a while.  That
way we can safely re-establish master-master replication as well, from
either end, without accidentally blowing away newly created mailboxes in
the degenerate case.

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm