That's promising that it should be doable. (yes, all I want is for the move to only occur once - duplicate messages is not a "move" at all) I'll forward your suggestions to the Thunderbird & Postbox teams.
In the meantime I'll continue to evaluate helpdesk systems and "collaborative inbox" products. Greg. On 06/08/2014 2:11 am, "Timo Sirainen" <t...@iki.fi> wrote: > 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.sulli...@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 <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. > >> > >> > >
