MBOX-Line: From tss at iki.fi  Fri Jun 11 13:00:46 2010
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006111006350.662@hsinghsing.panda.com>
References: <1768814180.483.1276267238967.JavaMail.root@dogfood.zimbra.com>
	<1276267479.22134.102.camel@kurkku.sapo.corppt.com>
	<alpine.OSX.2.00.1006110910440.662@hsinghsing.panda.com>
	<1276274718.22134.138.camel@kurkku.sapo.corppt.com>
	<alpine.OSX.2.00.1006111006350.662@hsinghsing.panda.com>
Message-ID: <1276286446.22134.149.camel@kurkku.sapo.corppt.com>

On pe, 2010-06-11 at 10:25 -0700, Mark Crispin wrote:
> On Fri, 11 Jun 2010, Timo Sirainen wrote:
> >> If MOVE is not atomic, then what is its point?
> > 1) Allowing user to move messages between mailboxes in situations where
> > a COPY would bring user over quota.
> 
> That presupposes a mail store in which COPY would bring the user over
> quota.  As with a database, there's no reason why that should be the case
> with a maildir type store.  A maildir store can use hardlink to implement
> COPY.

I once wondered about this. It would be nice if copied messages didn't
increase quota usage, because they really don't take much more of
physical disk space. But unless you're using filesystem quota, it's
difficult to calculate quota that way.

For example commonly used Maildir++ quota requires recalculating quota
quite often. The only way a recalculation could avoid counting copied
messages twice would be to keep track of the inodes that have link count
higher than 1, and then count them only once. This wastes memory and
requires stat()ing all files, which becomes horribly slow.

I guess with a database-type of storage where messages have refcounts
this would be easier. When message's refcount drops to zero, decrease
quota, if it gets back to non-zero, increase quota. When recalculating
quota, go through the message database and sum up non-zero refcounts.
I've a new mix-like mailbox format that actually could do that. I'd just
have to change the quota code to support this kind of a special case
format..

Anyway, even in such storage copied messages should increase the
MESSAGES count, and potentially fail the COPY if MESSAGES limit is
reached. This is probably pretty rare problem though.

> > 2) Simplify the operation for clients, also drop one round trip wait. I
> > guess this mainly would benefit some custom webmail developers that
> > develop against a specific server..
> 
> Pipelining eliminates this, except perhaps for a protocol link over a
> 300bps modem where the extra chattiness might matter.

Pipelining all of COPY+STORE+EXPUNGE doesn't really sound like a good
idea. If COPY fails, the messages are still expunged.


