57 lines
2.7 KiB
Plaintext
57 lines
2.7 KiB
Plaintext
MBOX-Line: From witold.krecicki at firma.o2.pl Fri Jun 11 06:47:09 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: <1276262838.22134.61.camel@kurkku.sapo.corppt.com>
|
|
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
|
|
<201006111454.51874.witold.krecicki@firma.o2.pl>
|
|
<1276262838.22134.61.camel@kurkku.sapo.corppt.com>
|
|
Message-ID: <201006111547.09949.witold.krecicki@firma.o2.pl>
|
|
|
|
On Friday 11 of June 2010 15:27:18 Timo Sirainen wrote:
|
|
> On pe, 2010-06-11 at 14:54 +0200, Witold Kr?cicki wrote:
|
|
> > 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).
|
|
>
|
|
> The problem is that I'd have to add a new internal "move" operation, and
|
|
> then quota code would also have to handle it, and there are probably
|
|
> many other places that would need to handle it. Also the whole move
|
|
> operation doesn't really even fit into Dovecot's internal design. It
|
|
> would be difficult to implement in any other way than copy+expunge (but
|
|
> with all the extra complexity in quota/etc code).
|
|
Still - is it worth the effort?
|
|
|
|
> Then there's the problem that servers can support multiple mailbox
|
|
> formats. Possibly even the same user's mailboxes can be in different
|
|
> formats. While MOVE might help with maildir, it wouldn't help with mbox.
|
|
|
|
There's also an option that server may fail with MOVE operation even if the
|
|
cp/st/ex is possible (and client must try cp/st/ex routine)
|
|
|
|
Anyway in most of setups it's known if the system is using maildirs (or
|
|
equivalent system in which move is efficient) or mboxes (or equivalent system in
|
|
which move is inefficient) and can advertise the extension or not accordingly.
|
|
|
|
--
|
|
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
|
|
|