On Thursday 03 Jan 2013 10:33:52 Alan McKinnon wrote: > On Thu, 03 Jan 2013 09:43 +0000 > > Peter Humphrey <[email protected]> wrote: > > Hello list, > > > > When kmail was upgraded to 4.9.3 last month it made a complete hash > > of my e- mail system. In the end I moved my user out of the way and > > created a new user. Importing the e-mails from a backup of the old > > version omitted large numbers of e-mails, including a lot of complete > > folders. I also noticed that kmail had not created a trash folder. > > So the kdepim devs STILL haven't fixed that one? Oh dear. > > tldr; longish post. Short version: Use something else. It's mail, not > software magic. > > I ran into something much the same long ago with kamil2 > around the 4.3 or 4.5 era. Imports wouldn't work, akonadi was displaying > essentially random mails in random folders in no special order, and I > was losing mail. > > Eventually, after much physical and spiritual pain, I figured that what > was really happening was probably akonadi importing the mail to > $SOMEWHERE and $AT_SOME_RANDOM_TIME would index it properly; it would > do this on the basis off $WHEN_IT_FELT_RIGHT_TO_DO_IT. > > This trick works awesomely well for caching thumbnails of my video > collection for xbmc. It works less well for my mail. It's disastrous > when the whole process is not documented, when the user has no > visibility into it and no defined way of seeing what's going on, not > even a progress meter. The traditional way of handling such > asynchronous indexing problems is to provide an option where the user > can force a re-index and the system will just chug along doing it > displaying progress. If the mail app suspends itself while doing this, > well that's fine, at least it ends in a reasonable time. But, kdepim at > that stage had no such option. > > One other thing I discovered back then: if I killed akonadi & kdepim > and rebooted out of sheer frustration, it would *throw* *away* all it's > temporary files form $SOMEWHERE as above and corrupt it's own database. > Leading to lost mail. If you just leave the damn thing alone for ages > and ages it eventually sorts itself out, but you can't see how far > along it is. > > Such shoddy alpha-quality software shipped and billed as enterprise > production-ready was more than I could bear, so I just switched mail > client to claws-mail. > > On 4.9.3 you are still experiencing something similar. Hmmm. Indicates > to me a high probability of a systemic problem with the projects > approach, something that is unlikely to ever get really fixed. In my > opinion kdepim2 is vastly over-engineered and an attempt to solve a > problem that does not actually exist. I recommend you use a different > mail app. > > As I mentioned in the tldr, it's a mail app. There are many mail apps > and none are super-special.
Thankfully, I'm still on kmail-1.13.7 and I am dreading the time that it will no longer be available. I've used kmail for so many years now that everything else I tried has been a great disappointment for me. Last time I tried to upgrade to kmail 2 some time early last year (for the 4th time) it made exactly the mess experienced by others, like: - duplicate/multiple messages when I tried to delete them - missing/disappearing messages - inability to show anything other than the Inbox folder on IMAP4 accounts I could swear that I waited for it to sync/resync, but I didn't leave the box running overnight to see if that would fix this problem. In all but one box I am not running a full KDE enchilada, so I don't know if this has something to do with it. I just hope that new devs will eventually take over this KDEPIM farce and something sane will surface for those of us who still want/need to use a mail client. -- Regards, Mick
smime.p7s
Description: S/MIME cryptographic signature
