MBOX-Line: From witold.krecicki at firma.o2.pl  Sat Jun 12 00:58:13 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006112111250.662@hsinghsing.panda.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006112352.05642.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006112111250.662@hsinghsing.panda.com>
Message-ID: <201006120958.13649.witold.krecicki@firma.o2.pl>

On Saturday 12 of June 2010 07:53:55 Mark Crispin wrote:
> On Fri, 11 Jun 2010, Witold Kr?cicki wrote:
> >> IMAP has no guaranteed means of removing a message.  Study the semantics
> >> of STORE and EXPUNGE carefully.  MOVE, on the other hand, requires that
> >> guarantee; and does not have the semantics of STORE and EXPUNGE.
> > 
> > I really don't get the point, please be more specific.
> 
> Neither STORE, nor EXPUNGE, promise that they will store or expunge
> anything.  They do, or not do, whatever seems fit according to their
> discretion.  Generally, what they decide to more corresponds to what the
> user intended.  But there's no promises.
> 
> Because of this, both STORE and EXPUNGE send back untagged responses
> stating what they actually did.  The client uses this to update its cached
> state of what is on the server.  If it were not for these untagged
> responses, the client wouldn't have a clue as to what is going on.
> 
> There are certain circumstances, such as when closing a mailbox in a
> client that does not cache offline state, that the client does not care
> what the server did beyond a vague presumption that that the server did
> more or less reasonably was what the user wanted.  For this reason, there
> STORE's .SILENT form, and the CLOSE command, exist.
> 
> A successful MOVE, on the other hand, is an unconditional guarantee that
> all the requested message(s) were moved.  But it it?  Similarly, a failed
> MOVE ought to be an unconditional guarantee that none of the requested
> messages(s) were moved.  But, once again, is it?
> 
> What happens when there is an error in the middle of the move?  Is there a
> state in which some messages were moved and others were not?  Is there a
> state in which some messages appear in both places (so it was a copy after
> all)?  Is there a state in which some messages vanished completely?
> 
> The only way that you can prevent all of these states is with a
> simultaneous commit in which a failure of either side (remove from source,
> insert in destination) completely undoes everything.  Locking by itself
> isn't good enough; locking only prevents external races.  You still have
> a chicken-and-egg situation in which neither side can safely commit
> without confirmation that the other side has committed.
> 
> There are ways to do it.  But these are not simple nor commonly
> understood.  If I talk about this stuff with most programmers their eyes
> glaze over.
> 
> Not even the (much simpler) synchronization timing requirements of IMAP
> are well-implemented.  Timo's server and my Panda server are the only ones
> that do it correctly in all circumstances (I'm hoping to add my new server
> to the list).
> 
> So let's say that we punt and say that an error is an error and we'll
> break the all-of-nothing guarantee of IMAP.
This guarantee is a myth that is not working in eg. Maildirs. 
The same problems that appear with COPY or EXPUNGE in those critical 
situations but nobody is thinking about removing COPY or EXPUNGE from the 
protocol.

This is an option so if you cannot implement it properly - don't. If you can - 
why not?
And about uncertainity:
<quote>
      The EXPUNGE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox.  Before
      returning an OK to the client, an untagged EXPUNGE response is
      sent for each message that is removed.
</quote>
What if the server deletes 3 out of 10 messages and then is struck by a 
filesystem failure (cannot delete remaining 7, cannot undelete of the first 3)? 
This situation is (formally) not covered in the protocol, server cannot send 
untagged EXPUNGE responses for those 3 messages (because then it would have to 
send OK) and it cannot send OK because EXPUNGE after a success removes ALL 
messages with \Deleted flags... It should send NO but then the client would 
think that no messages were deleted permanently...


-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

