Re: [Evolution] Evolution maximum email file size



On Sun, 2008-06-22 at 04:21 -0400, Internaut at Large wrote:
Greetings,

On Sat, 2008-06-21 at 21:13 -0430, Patrick O'Callaghan wrote:
On Sat, 2008-06-21 at 18:43 -0400, Internaut at Large wrote:
Greetings,

On Sat, 2008-06-21 at 11:39 -0400, Damon Allen wrote:
In Windows, Outlook is limited to a maximum of 2 GB for email storage 
before problems start occurring.  This is due to a preemptive limit in 
Outlook based on a Windows problem with dealing with large files.  My 
first question is in Linux is there a problem with large files which 
would cause the OS to become unstable?  Secondly does Evolution have a 
limit of email file size based on this OS limit?

Interestingly enough, I just ran into this problem.  Not on the
Evolution side of things, but on the IMAP side of things.  Apparently my
linux server that serves my imap won't handle a mail file that is in
excess of, approximately 200 gig. (a little over 30,000 mail messages,
some with lots of attachments) when on that system, trying to open the
file gives me the error message "cannot handle a file that large of that
type" with anything.  So I basically poured it through formail and
procmail to filter it to smaller boxes, so it can handle it.

Unfortunately, evolution doesn't deal with MH or maildir files very
well, so that wasn't really an option, it had to be a large spool file.

I don't understand. What has Evo got to do with the file format on the
IMAP server?

Because, the version of evolution I'm running (2.10.3, on FC-7) does not
actually remove things from the IMAP server that is completely capable
of MH and Maildir styles of serving, and it was frustrating to use evo
to mark them as deleted, and then have to go in with mutt, local on the
machine, just to expunge them, when they stacked up too much.  I
complained (and filed a bug) about this several years ago, when I first
noticed it (no, I don't remember when) but I just live with it, amongst
the other quirks of Evolution.

Sorry, I still don't get it. Evo marks messages as deleted and later (on
the user's command) sends an Expunge command, which the IMAP server
executes. Are you saying a) Evo *doesn't* send the Expunge, or b) that
the server doesn't execute it? It's hard to believe (a) since I've been
using Evo since version 1 and have never seen this happen under any
circumstance. If it is happening it would be a serious bug. If it's (b)
then obviously there's something wrong with the server, but that has
nothing to do with Evo. Evo has no direct access to the server's mail
file and only interacts with the server through IMAP commands, which are
completely agnostic regarding file formats. You say you can expunge
using mutt on the server. Is this mutt using the mail file as a local
folder, or is it connecting (locally) to the mail server? Can you do it
via mutt from your client machine? If not (which I suspect is the
answer) then there is clearly a configuration problem with the server.
Perhaps to do with file permissions, I don't know. Or maybe there's
isn't enough /tmp space to copy a 200GB mail file in order to execute
the expunge.

(The latest is, for some reason, over
the last several days, the local repository on my computer doesn't seem
to work or resolve, the file portion of the path to the local spool file
seems to not want to exist, and is greyed out when I try to
re-initialize it, at some point, I'll go into the file with an xml
editor, and just add it back in, but ... really, one shouldn't have to
do that.)

You might want to consider a file-per-message server such as Cyrus,
Courier or Dovecot. File-per-folder systems are not scaleable. Every
time you delete and expunge a message from the middle of your 200GB
file, the server has to copy all 200 gigs.

I know.  But it is what evolution plays well with, unfortunately.  And
yes, I'm using Courier on the server, btw.

Evo works perfectly well with Cyrus, which is what I use. I believe it
also works with other popular IMAP servers including Courier and
Dovecot.

poc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]