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@iki.fi wrote:
On 04 Aug 2014, at 14:12, Greg Sullivan greg.sullivan@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.