Is atomic MOVING of messages between IMAP folders possible?

[Greg Sullivan]

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" <tss at 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.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.
> >>
> >>
>
>