134 lines
5.4 KiB
Plaintext
134 lines
5.4 KiB
Plaintext
MBOX-Line: From snowjn at aol.com Mon Jun 14 17:10:16 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: John Snow <snowjn@aol.com>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] MOVE is a pipeline
|
|
In-Reply-To: <alpine.OSX.2.00.1006141604420.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> <201006150103.52513.witold.krecicki@firma.o2.pl>
|
|
<alpine.OSX.2.00.1006141604420.662@hsinghsing.panda.com>
|
|
Message-ID: <4C16C4E8.7010008@aol.com>
|
|
|
|
|
|
|
|
Mark Crispin wrote:
|
|
> 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.
|
|
How is that different than a UID expunge? A client specifies which
|
|
specific message it
|
|
wants expunged. You said earlier that the Server can still decide not
|
|
to expunge it, for
|
|
various reasons. Why doesn't a move have the same option? As long as
|
|
the server
|
|
reports the results of the move command, as suggested earlier by Stuart,
|
|
then no matter
|
|
the outcome of the copy, the client and server would be in sync.
|
|
|
|
>
|
|
> 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.
|
|
> ------------------------------------------------------------------------
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100614/f68d1d6d/attachment.html>
|