On Tue, 28 Jun 2011 08:58 +0100, "David Carter" <dpc22@xxxxxxxxx> 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@xxxxxxxxxxx ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
