Is atomic MOVING of messages between IMAP folders possible?

[Greg Sullivan]

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.

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)

Thanks so far.

Client is Postbox & Thunderbird on Windows. (I realise Postbox is based on
Thunderbird)

Greg.




On 4 August 2014 22:03, Reindl Harald <h.reindl at thelounge.net> wrote:

>
>
> Am 04.08.2014 um 14:00 schrieb Timo Sirainen:
> > On 04 Aug 2014, at 10:44, Greg Sullivan <greg.sullivan at sullivang.net>
> wrote:
> >
> >> I would like to use a shared IMAP account, with multiple users
> accessing it
> >> simultaneously.  The users would take ownership of messages by first
> >> attempting to MOVE the messages from the Inbox,  into their private IMAP
> >> folder, still within the same account. Now, since there will be multiple
> >> users competing for the same messages, I naturally want only ONE of the
> >> simultaneous moves to be successful at a time.
> >>
> >> So far, this isn't working. If I do the move from two clients,
> >> simultaneously, the messages can go to *both *destination folders -
> >> duplicates can result.
> >>
> >> Is it possible to configure Dovecot and/or an IMAP client to behave the
> way
> >> I want it to? If the answer to this is YES, then I'll offer my config
> >> details. If the answer is NO, the next question is - do any email
> systems
> >> at all behave the way I want? (I tried a hosted Exchange/OWA service -
> it
> >> has the same problem)
> >
> > Dovecot doesn't even attempt to do atomic MOVEs. I don't think any
> server will. If you can change the client code, you could use CONDSTORE
> instead, which does give atomic STOREs.
>
> Internet Message Access Protocol (IMAP) - MOVE Extension
> http://tools.ietf.org/html/rfc6851
>
> well, both, client and server would need to support it
> rely on that is unlikely for many years
>
>