Is atomic MOVING of messages between IMAP folders possible?

[Reindl Harald]

Am 06.08.2014 um 12:15 schrieb Greg Sullivan:
> Jochen,
> I don't have any in-depth knowledge of the IMAP protocol. I'm just saying
> that given that IMAP is designed for concurrent access from multiple
> clients, I would have expected it to behave much better when more than one
> person attempts to move a message, that's all. I was gobsmacked when I
> discovered that duplicates could easily occur!
> 
> Quote from the IMAP wikipedia page:
> Internet Message Access Protocol (IMAP) is a protocol for e-mail retrieval
> and storage developed by Mark Crispin in 1986 at Stanford University as an
> alternative to POP. IMAP unlike POP, specifically allows multiple clients
> simultaneously connected to the same mailbox, and through flags stored on
> the server, different clients accessing the same mailbox at the same or
> different times can detect state changes made by other clients.

that's the theory

"can detect" -> when and how in case of concurrency
things are not that easy because you have anyways
network latency as part of the game

> On 6 August 2014 04:00, Jochen Bern <Jochen.Bern at linworks.de> wrote:
> 
>> On -10.01.-28163 20:59, Greg Sullivan wrote:
>>> 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)
>>
>> How would it be of any use to the passive client that the *operation* is
>> atomic when (as far as I can see, which admittedly mightn't be much)
>> there is no way defined in the IMAP protocol to atomically *notify* it
>> of said change?
>>
>> IMAP IDLE, for example, may inform it that one message disappeared from
>> mailbox X and one popped up in mailbox Y - not that these two are
>> actually the same message, still have the same set of flags set, etc..
>> That's for the client to find out by specific requests - which already
>> breaks the atomicity and allows for a race condition between clients.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20140806/bc73afa5/attachment.sig>