MBOX-Line: From mrc+imap at panda.com  Mon Jun 14 15:52:21 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <201006150012.43889.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006142256.29781.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141411190.662@hsinghsing.panda.com>
	<201006150012.43889.witold.krecicki@firma.o2.pl>
Message-ID: <alpine.OSX.2.00.1006141528400.662@hsinghsing.panda.com>

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.

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

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

> lie

The burden of proof is on you.

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

>> The only way to do it in Maildir is to use a database that has
>> simultaneous index update.  But then it is not Maildir; it is a database
>> that happens to have files that look like a Maildir.  And any access of
>> the Maildir as a Maildir will encounter the races and potentially
>> invalidate the database.
> So how can it be that it is working for some people?

The two major Maildir based servers use private extensions to Maildir to
work around the deficiencies which make raw Maildir unsuitable for IMAP.
These extensions do not, and were not intended to, provide an atomic move
operation.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
