wasm-demo/demo/ermis-f/imap-protocol/cur/1600095161.22807.mbox:2,S

48 lines
1.9 KiB
Plaintext

MBOX-Line: From witold.krecicki at firma.o2.pl Mon Jun 14 12:08:34 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:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.OSX.2.00.1006141014400.662@hsinghsing.panda.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
<alpine.OSX.1.10.1006140942380.2640@mbp.lyndon.corp.flock.com>
<alpine.OSX.2.00.1006141014400.662@hsinghsing.panda.com>
Message-ID: <201006142108.34481.witold.krecicki@firma.o2.pl>
On Monday 14 of June 2010 19:33:39 Mark Crispin wrote:
> On Mon, 14 Jun 2010, Lyndon Nerenberg wrote:
> > When I maintained Esys' IMAP server, a 'single instance' message store
> > was *the* most widely requested feature from our customer base. This was
> > in 1997, and I doubt we were the first to do it.
>
> Single instance message stores existed in the 1980s. IMAP's architecture
> was influenced by these; hence the rule that messages are immutable.
>
> The new message store that I am designing now is single instance. It is
> targeted for CAstor where there is no filesystem at all; just pointers.
Then why not design it so that MOVE is possible and easy?
>
> > Note
> > that even with the single instance store, it is still necessary to
> > perform a copy of the file if the source and destination mailboxes reside
> > on different filesystems.
>
> The same problem exists with MOVE, of course. Anyone who thinks that
> rename() is a solution hasn't studied what rename() actually does.
I never said that rename() is a solution.
> > I cannot understand your claim that using link() in this case is a
> > "hack."
>
> It's just one of many unsubstantiated claims that he makes.
Name other ones, please.
--
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