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