[Imap-protocol] IMAP MOVE extension

Mark Crispin mrc+imap at panda.com
Fri Jun 11 08:57:05 PDT 2010


On Fri, 11 Jun 2010, Dave Cridland wrote:

> Depending on your server design, this is either very easy, or else

> very hard - of course, since it's optional, it'd seem likely that

> where it's hard it'd not be supported.


Correct.

Commands in IMAP are atomic; thus this MOVE operation must be atomic.
It is simply impossible to do an atomic MOVE with many stores.

Note that not even a one-file/one-message store (ala maildir) can do MOVE
atomically. Each file has to be renamed separately. That's not atomic!

The one type of store that can do an atomic move is a database type store
where it would be an index update. In that case, you can lock the two
indices.

MOVE is a classic example of something that sounds good and useful if you
have not thought these issues through. I have. It was no oversight that
there is no MOVE in IMAP. It was a carefully thought-out decision.


> One thing that concerns me is that there is no way to undo this

> operation - traditionally, only EXPUNGE and DELETE have been

> irrevocable actions in IMAP, this adds one more.


Correct.


> The way to combat this is to make it merely mark \Deleted the

> original message - except then this eradicates any benefit to the

> command at all for clients. (Since one could either do MOVE/UID

> EXPUNGE, or else COPY+STORE/UID EXPUNGE).


And these commands can be pipelined.


> And there has to be very significant advantage for clients, across a

> wide deployment, for most clients to bother implementing it - right

> now, I don't see it.


There is no advantage, since clients have to implement both methods.

Note that in the one case where you can implement MOVE (see above), there
is no particular benefit (other than the atomic lock) over pipelining
because in the database the COPY operation is also an index operation.

The case that would benefit from MOVE can't implement MOVE. The whole
idea of "wow, I can rename my maildir files instead of copying and
deleting" is fatally flawed, because it is not atomic. It's the same
problem as RENAME when a hierarchy is involve.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.


More information about the Imap-protocol mailing list