61 lines
2.7 KiB
Plaintext
61 lines
2.7 KiB
Plaintext
MBOX-Line: From mrc+imap at panda.com Mon Jun 14 10:33:39 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc+imap@panda.com>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] IMAP MOVE extension
|
|
In-Reply-To: <alpine.OSX.1.10.1006140942380.2640@mbp.lyndon.corp.flock.com>
|
|
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
|
|
<201006112113.56572.witold.krecicki@firma.o2.pl>
|
|
<alpine.OSX.2.00.1006111214020.662@hsinghsing.panda.com>
|
|
<201006112352.05642.witold.krecicki@firma.o2.pl>
|
|
<alpine.OSX.1.10.1006140942380.2640@mbp.lyndon.corp.flock.com>
|
|
Message-ID: <alpine.OSX.2.00.1006141014400.662@hsinghsing.panda.com>
|
|
|
|
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.
|
|
|
|
I've already tested the basic concept with a stubbing implementation in my
|
|
existing mix store architecture. The next step is to get rid of the
|
|
non-stubbing mailbox that is currently used as the target.
|
|
|
|
The quota issue is a separate matter. Since there is no longer any
|
|
significant per-user space in this new store, quotas are important only if
|
|
it is desirable to recover space by dropping the last pointer to a
|
|
message. But in an archive/retention environment, it may not be permitted
|
|
to recover the space, and/or space recovery is done independently of what
|
|
a user does (e.g., "destroy all emails after 5 years").
|
|
|
|
Either way, quota should not matter on copy vs. move. Either the copy of
|
|
message text is unavoidable, or the quota issue can be avoided by making
|
|
another pointer to the inode or database record.
|
|
|
|
> 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.
|
|
|
|
The basic flaw is the idea that message texts exist within the mailbox.
|
|
That is inherited from local file mailboxes of the past.
|
|
|
|
> 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.
|
|
|
|
-- Mark --
|
|
|
|
http://panda.com/mrc
|
|
Democracy is two wolves and a sheep deciding what to eat for lunch.
|
|
Liberty is a well-armed sheep contesting the vote.
|
|
|