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