MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 16:03:52 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] MOVE is a pipeline
In-Reply-To: <alpine.OSX.2.00.1006141528400.662@hsinghsing.panda.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006150012.43889.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141528400.662@hsinghsing.panda.com>
Message-ID: <201006150103.52513.witold.krecicki@firma.o2.pl>

On Tuesday 15 of June 2010 00:52:21 Mark Crispin wrote:
> On Tue, 15 Jun 2010, Witold Kr?cicki wrote:
> > For me 'all messages that have the \Deleted flag set' means '*all*
> > messages that have the \Deleted flag set'. So expunging just some of the
> > messages is in fact a partial failure that is reported as a success.
> 
> No.  You still do not understand.  There is no such thing as "partial
> failure" in EXPUNGE.  You are confusing "non-deterministic success" with
> "partial failure".
> 
> There are many reasons why the result of EXPUNGE may be different from the
> client's expectation.  The client may not have expunge rights.  Another
> client may delete some messages, or undelete other messages.
> 
> EXPUNGE is NOT documented to expunge what the client thinks are deleted
> messages.  EXPUNGE expunges what the server thinks are deleted messages,
> IF the server sees fit to do so.  The server then says what it did.  And
> this is a success.
> 
> Not even UID EXPUNGE expunges what the client thinks are deleted messages.
> UID EXPUNGE merely limits the scope of expunging to certain messages.
> Nothing prevents the server from refusing to expunge some messages; nor
> even from expunging messages that are outside of the scope of UID EXPUNGE
> (e.g., some other session expunged the affected messages).
> 
> These are not failures, nor "partial" success.  They are the way that
> EXPUNGE works; and this is a complete success.
Then the specification (that YOU wrote) is unclear about that.
 
> MOVE, on the other hand, would go into a class of commands that advertise
> client-determinate result.  You are proposing adding a completely new
> class of command to IMAP.
The specification of MOVE is (in this matter) the same as EXPUNGE. I can make 
it clearer though.
 
> > The same applies for MOVE implemented by rename(). Untagged EXPUNGE
> > responses for all moved mails, no responses for not moved mails. The
> > same kind of 'partial failure' that is existing with EXPUNGE.
> 
> That is not an atomic MOVE.  That is a non-atomic move.
Then EXPUNGE is not atomic, as You've stated earlier.

> Nor does it prevent the filesystem timing races, particularly when the
> source and target are on different filesystems.  Depending upon the
> implementation, the timing race results in one of:
>  	duplicate on both source and target
>  	vanish from both source and target
And what about the same filesystem?
 
> > lie
> 
> The burden of proof is on you.
You're stating claims without proper arguments so I don't care. 
> >> Either you are lying, or you are so inexperienced that you do not yet
> >> understand the types of timing races that are possible in filesystems.
> > 
> > Show me those races, you are using claims without any proper
> > argumentation or real life examples.
> 
> My rates for consulting services start at $10,000.
> 
> The burden of proof is on you to demonstrate that there are no races.
YOU are claiming that there are races so prove that there are.

I claim that there are pink elephants living on the dark side of Pluto that 
will prevent those races. The burden of proof is on you to demonstrate that 
there are no such elephants.

-- 
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

