31 lines
1.3 KiB
Plaintext
31 lines
1.3 KiB
Plaintext
MBOX-Line: From lyndon at orthanc.ca Mon Jun 14 09:58:29 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Lyndon Nerenberg <lyndon@orthanc.ca>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] IMAP MOVE extension
|
|
In-Reply-To: <201006112352.05642.witold.krecicki@firma.o2.pl>
|
|
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>
|
|
Message-ID: <alpine.OSX.1.10.1006140942380.2640@mbp.lyndon.corp.flock.com>
|
|
|
|
> COPY is by definition a slow operation. Using hardlinks etc. is a performance
|
|
> hack, not a normal method.
|
|
|
|
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.
|
|
|
|
The driver for this feature was the quota issue; the backend message store
|
|
was fast enough that hardlinks didn't noticeably speed things up. 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.
|
|
|
|
I cannot understand your claim that using link() in this case is a "hack."
|
|
What is it you think link() is for?
|
|
|
|
--lyndon
|
|
|