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.

