37 lines
1.7 KiB
Plaintext
37 lines
1.7 KiB
Plaintext
MBOX-Line: From witold.krecicki at firma.o2.pl Fri Jun 11 05:54:51 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
|
|
Date: Fri Jun 8 12:34:43 2018
|
|
Subject: [Imap-protocol] IMAP MOVE extension
|
|
In-Reply-To: <D159C4D6-24D9-4BF8-98EF-E5E1EC26028C@iki.fi>
|
|
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
|
|
<201006111437.03613.witold.krecicki@firma.o2.pl>
|
|
<D159C4D6-24D9-4BF8-98EF-E5E1EC26028C@iki.fi>
|
|
Message-ID: <201006111454.51874.witold.krecicki@firma.o2.pl>
|
|
|
|
On Friday 11 of June 2010 14:44:43 Timo Sirainen wrote:
|
|
> On 11.6.2010, at 13.37, Witold Kr?cicki wrote:
|
|
> >> 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.
|
|
> >
|
|
> > And how hard it would be to really implement it in Dovecot?
|
|
>
|
|
> Much more difficult than I originally thought.
|
|
Well, 'brutal' (and nonsense in a way) implementation would be to 'internally'
|
|
do copy messages listed and then expunge messages that were copied (at least
|
|
there is no setting flags).
|
|
I thought on including the statement that if it would take more time to do
|
|
'move' than to do cp/st/ex routine the server SHOULD NOT provide MOVE
|
|
extension.
|
|
--
|
|
Witold Kr?cicki
|
|
|
|
Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
|
|
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy,
|
|
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513
|
|
|