On Mon, 2005-03-28 at 14:09 -0500, Jeffrey Stedfast wrote: > no > > > If not, would it be a > > hard/difficult/excessively time consuming thing to facilitate? > > wouldn't necessarily be difficult to implement, but is it really needed? > I've seen a few people ask for this but generally it's because of 1 of > two reasons: > > 1. evo had a bug downloading pop mail where it would refetch some > messages (server changed the headers usually, by changing/adding > [X-]Status: headers) > > 2. people get multiple copies of the message through different paths > (one via a mailing list and one direct). The problem I have been having is that a duplicate copy of the message were at some point being created by a bug in Evolution. I'm with you on this one, makes sense just to fix the code. The second problem I have is that several times I've attempted to sync mail stores, wound up popping my box where "leave messages on server" was set and then subsequently pulled down enough messages to make me want to pull my hair out. Whilst I realize the latter is a user error issue, and additionally IMO a "pop-is-an-archaic-and-in-dire-need-of-functionality-updates" error, its still a problem for me. One or two messages is no big deal, but I deal with a volume of 1,000-1,500 messages per day, and when something like this occurs, its a real PITA to go and manually delete the duplicates. Looks like this is something I'll have to try to implement myself, thanks for the suggestions I'll give this a good look and submit back whatever success I might have. > it wasn't removed. the change was simply that the "On This COmputer" > folder heirarchy was changed such that it was always mbox - it made the > directory layout much simpler. IMHO simpler != better. I absolutely despise mbox. Its tolerable if you have only a few messages, but again I'm dealing with an obsene volume and a rather large virtual-folder heiarchy. Having messages stored in indivual files is more of a PITA to manage (I certainly won't contest that) but with the speed of drives and their cache sizes, and additionally blazing fast filesystems like ReiserFS which handle lots of small files with relative ease, I can't stay away from Maildir, not to mention what happens when a nice Inbox file several hundred megs. > could we have used maildir instead? sure, but it was decided to go with > mbox because that's what other unix mailers use. (mbox and maildir both > have their drawbacks) Rather than start a "is bigger/better/faster/stronger" than yours "discussion" I'll cut to the chase and enquire about where I might do some reading to hack around to re-enable the use of Maildir. Additionally, due to the volume of messages I keep in my local mailstore, having all of the folders "virtual" with indexes used to speed up the process of restoring everything to its former appearance is expensive. I understand that there is simply a cost associated with storing the number of messages that I do, but I am curious what if any benchmarks there were made against the previous methods in past versions versus the current method? Thanks for the quick response! Cheers, James -- James Couzens, Programmer __ ___ _ ___ _____ \ \ / (_)______ _ _ __ __| | |_ _|_ _| | UNIX Administration \ \ /\ / /| |_ / _` | '__/ _` | | | | | | Website Hosting \ V V / | |/ / (_| | | | (_| | | | | | | Network Services \_/\_/ |_/___\__,_|_| \__,_| |___| |_| | Software Development -------------------------------------------------------------------- Wizard IT Services - http://www.wizard.ca
Attachment:
signature.asc
Description: This is a digitally signed message part