Is atomic MOVING of messages between IMAP folders possible?

Timo Sirainen tss at iki.fi
Tue Aug 5 16:11:36 UTC 2014


Note that MOVE isn't atomic even between moving within one user's folders. The MOVE RFC itself also doesn't say anything about it ever having to be atomic. Although if by atomicity you mean that you simply want to make sure that the same source mail can't be MOVEd twice, that would be doable with some work I think. Even for full conversations (without partial failures).

On 05 Aug 2014, at 13:19, Greg Sullivan <greg.sullivan at sullivang.net> wrote:

> Thanks Timo, and no, I can't (easily) change the code of the client.
> 
> I must say I am extremely disappointed that intra-account moves are not
> atomic. As far as I can tell, IMAP was designed to allow shared access, so
> in my opinion this operation should be atomic.  Heaven FORBID that I should
> ask for entire conversation moves to be atomic as well. (which is really
> what I want)
> 
> Looks like a bloatware - sorry - helpdesk system - is what I will need to
> use.
> 
> Greg.
> 
> 
> On 4 August 2014 22:44, Timo Sirainen <tss at iki.fi> wrote:
> 
>> On 04 Aug 2014, at 14:12, Greg Sullivan <greg.sullivan at sullivang.net>
>> wrote:
>> 
>>> Yes, both client and server support IMAP MOVE, and both also support
>>> CONDSTORE.
>>> 
>>> I have tried both with and without CONDSTORE enabled in the client, with
>>> the same result.
>> 
>> With CONDSTORE I was thinking you could do it something like:
>> 
>> 1 FETCH 1 (FLAGS MODSEQ)
>> * 1 FLAGS () MODSEQ 12345
>> 2 STORE (UNCHANGEDSINCE 12345) 1 +FLAGS $AtomicMove
>> 3 MOVE 1 elsewhere
>> 
>> If another client attempts the same, either 1 will return $AtomicMove in
>> flags -> abort or 2 will fail with NO. But you should still handle failures
>> if the client/connection dies between 2 and 3 or 3 fails for some reason.
>> 
>> But, of course if you can't change the client code to do this then it
>> doesn't help.
>> 
>>> I am very confident IMAP MOVE is actually being invoked, because
>>> intra-account moves occur extremely rapidly. (much faster than
>>> inter-account moves, which of course is a copy & delete)
>> 
>> Inter-account physically copies the data (FETCH + APPEND + EXPUNGE).
>> Alternative to MOVE is COPY + EXPUNGE, which is just as fast as MOVE.
>> Dovecot actually implements MOVE by internally doing a COPY + EXPUNGE.
>> 
>> 



More information about the dovecot mailing list