MBOX-Line: From mrc+imap at panda.com  Mon Jun 14 16:44:53 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: <201006150103.52513.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006150012.43889.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141528400.662@hsinghsing.panda.com>
	<201006150103.52513.witold.krecicki@firma.o2.pl>
Message-ID: <alpine.OSX.2.00.1006141604420.662@hsinghsing.panda.com>

On Tue, 15 Jun 2010, Witold Kr?cicki wrote:
> Then the specification (that YOU wrote) is unclear about that.

The specification is quite clear that the server expunges what it sees as
being deleted, NOT what the client thinks is deleted.  If it expunged
client-deterministic messages, it would take an argument.

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

No.  MOVE takes a message set argument.  That makes its behavior
client-deterministic.

You are proposing adding a command in the client-deterministic set by its
syntax, yet implementing it as a non-deterministic command.  This is a
completely new class of command.

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

There is no meaning to "atomic" vs. "non-atomic" in EXPUNGE.

Each untagged EXPUNGE response has immediate impact, and nothing prevents
other responses from being interspersed.  For example:
 	* 5 EXISTS
 	* 2 EXPUNGE
 	* 3 FETCH FLAGS (\Seen)
 	* 2 EXPUNGE
tells us that there are 3 messages, and that message 2 has the \Seen flag.

COPY, on the other hand, is atomic; with all-or-none effect.  One of the
very first changes post-IMAP2 was to abolish the untagged COPY response.
Client authors at the time hated that response and the possibility of
partial success.  All contemporary implementations were either atomic
already or were fixed to be atomic.

If you wanted non-atomic COPY, the time to have spoken up in defense of it
was c. 1992.  Hop into your time machine.

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

Same thing.

Take a look at how rename() is actually implemented.  Journaling and the
buffer cache covers up a good deal of it these days, but the race still
exists.  If it didn't, there would never be a need for fsck.

What may be confusing you is the fact that locking in the kernel prevents
most user-level races.  But that only holds for a single file.

Those locks aren't always effective.  Unlike link(), the target of
rename() can exist.

NFS adds further complications; yet a big advertising point for Maildir is
that it purports to be NFS-safe.  NFS is non-atomic on several operations
that are atomic on most local filesystems, including some surprising ones.
Those differences ARE application-visible.

>> The burden of proof is on you.
> You're stating claims without proper arguments so I don't care.

This is not philosophy or law.  The thing that matters is who is right.
Presentation does not count.

>> 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 don't have to prove anything.

You want the change.  You have to prove that the change is not harmful.

If, and when, you offer what you claim to be proof, you then have to allow
it to be tested.  So far, you have offered nothing that can be tested.

Where is the source code that purports to demonstrate atomic move of
multiple messages in Maildir?

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