MBOX-Line: From tss at iki.fi  Fri Jun 11 05:09:55 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: <201006111115.19660.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<23852.1276246771.199346@puncture>
	<201006111115.19660.witold.krecicki@firma.o2.pl>
Message-ID: <20131949-0279-4455-8FB9-99E4030A6904@iki.fi>

On 11.6.2010, at 10.15, Witold Kr?cicki wrote:

> On Friday 11 of June 2010 10:59:31 Dave Cridland wrote:
>> Depending on your server design, this is either very easy, or else
>> very hard - of course, since it's optional, it'd seem likely that
>> where it's hard it'd not be supported.
> That's sure, that's why it's an option.  In most popular IMAP servers that use 
> Maildirs this is a simple 'move' operation, with I/O cost of next to nothing 
> (assuming that the whole user account is on one FS of course).

I once thought about implementing MOVE operation to Dovecot to improve speed. But then I realized that if client sends STORE \Deleted and EXPUNGE in same IP packet, I can just optimize away the rename()s caused by STORE. The remaining link()+unlink() should then be about as fast as rename(). The only exception is OSX with HFS filesystem, where hard links are really inefficient.

The main potential benefit I see for MOVE is to avoid "out of quota" error when moving messages. The biggest problem has been clients that delete messages by moving them to Trash, and then users complain that they can't get back to under quota because they can't delete messages. But that is also easily solvable by giving somewhat higher quota limit to Trash mailbox.

People (webmail developers mainly) still once in a while ask me to implement MOVE, but I think it's mainly about convenience to them.


