On Friday 11 of June 2010 17:57:05 Mark Crispin wrote:
> 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.
That's why it's an option, not a requirement.
> 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!
In this way COPY is only atomic if destination mailbox is locked, so the only
problem with maildir store is locking two mailboxes simultanously
> 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.
And this type of store is getting more popular in large deployments
> 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.
Correction - desktop clients. Web-based clients can be 'move-only' if are
deployed over servers which support MOVE operation.
Also, the implementation of MOVE method in clients is, in most cases, not a
problem at all.
> 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.
Depends on DB design.
> 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.
Maildirs can implement move (as an atomic operation) as long as locking two
mailboxes is permitted.
Database-backed designs can implement atomic move easily.
I don't want to force anyone to implement MOVE extension in their servers, and
I know that probably most popular filesystem-backed servers won't use it. But
the example of AOL (as mentioned by John Snow) shows that there is a need for
this functionality to be standarized so that clients that want to use it won't
need to check IMAP server domain name to figure out if it can use eg. XAOL-
MOVE.
--
Witold Kr?cicki
Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy,
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513