Bug 118341 - local cache of maildir contents not updated
Summary: local cache of maildir contents not updated
Status: RESOLVED WORKSFORME
Alias: None
Product: kmail
Classification: Applications
Component: maildir (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 147206 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-14 20:23 UTC by John Gilmore
Modified: 2013-04-14 15:21 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Gilmore 2005-12-14 20:23:24 UTC
Version:           1.1.2 (using KDE KDE 3.4.2)
Installed from:    Debian testing/unstable Packages

Kmail never does update it's idea of what the contents of the maildir are. This basic problem shows up in many ways, and in many places. The following bugs are symptoms of this basic problem:

Bug 108373,Bug 40949,Bug 42415,Bug 49310, and I'm sure many others that I haven't taken the time to track down.

In particular, note the following comment by jdmetz:

kmail has a "Refresh Local IMAP Cache" option under File, sounds like it needs the same for Local Folder Cache.

The thing is, we can get 90% of this quite easily, by losing the indexes on request.

If I "rm ~/Mail/.*" and restart kmail, 90% of things just work. So, do the same thing, but automatically and without having to restart kmail.

The other 9% involves updating the filenames before the above to reflect status information that hasn't been saved into the maildir format yet, so as not to lose it over the change. I suppose that would be a bug, but it would be MUCH better than the plethora of problems not having this function causes.

The last 1% involves going through the code and insuring that every bit of status information is saved in maildir format filenames, and correctly restored after the rescan. That'd be icing on the cake, but cake still tastes great without the icing, does it not?

This bug report is filed after the following IRC exchange:

dorky: I have me email stored locally as a "maildir" format thing. Kmail isn't displaying all of the emails. Why would kmail not display an email for which a file exists?

dorky: Thought I'd ask here incase anybody knew the answer right off the top of their heads. Save me having to manually disect the important email to get at the attachments...

dorky: It'd also be nice to get that email back for other reasons. The file is there, the text in the file looks fine, the name of the file is 1134081821.9859.vAo7a:2,S

dorky: Well, I figured out how to fix it. Kmail keeps index information, which it (wrongly) considers authoritive, in dot files in the main directory. Removing these indexes caused kmail to re-scan the actual mailboxes and update it's idea of what exists and what doesn't.

pusling: dorky: I have same experiences when using mutt on same maildir as kmail while kmail is running. I think it is a way to speed kmail up
dorky: pusling: Yes, I think the mere existance of stored indexes in my ~/Mail directory is disturbing. It indicates that Kmail isn't looking at the actual files and directories on disk - it's going off of what it knows, even over restarts. There should be, but isn't, an option to re-scan. And rescanning should happen periodically anyway. But it doesn't.

dorky: To sum up, it means that kmail can't and won't play nicely with anyone else accessing the maildir.

pusling: yes. aggreed. But the alternative is a much slower kmail, I think. my kmail starts in seconds scanning all mailboxes-indexfiles, my mutt starts in minutes only scanning inbox

dorky: We *CAN* have it both ways! It just has to periodically rescan in the background, instead of taking it's view of the world as the gospel truth forever and ever amen.
dorky At the very least it should rescan when it KNOWS that there is a difference. Like if you delete a message from the command line, kmail won't accept that it's deleted.

jdmetz: dorky: kmail has a "Refresh Local IMAP Cache" option under File

jdmetz: dorky: sounds like it needs the same for Local Folder Cache
pusling yup

dorky: More! it needs to do so automatically under some circumstances.

dorky: Though manual would certianly be MUCH better than nothing. I want a toolbar button :)

pusling: but some kmail faq clearly states that you should not access the maildirs while kmail is running :/

dorky: But these effect persist EVEN OVER RESTARTS OF KMAIL!!!!

dorky: and besides, isn't a large part of the point of the maildir format to allow parallel access without messing around with locking?

pusling: alias mutt="kill `pidof kmail ` ; mutt" ;)

dorky: I don't think that alias would fix the problem.

pusling: dorky: but report it on bugs.kde.org - and let us see what happens ;) But some 
kmail developers just don't care much for userwishes
Comment 1 Matthew Toseland 2007-05-05 15:42:45 UTC
Also related to #55421. Not being able to use procmail with kmail is *very* annoying: The way to fix it is either to refresh local folders periodically, or to allow to add maildir accounts without having to pull the mails into local folders. 
Comment 2 Thomas McGuire 2007-06-25 22:34:20 UTC
*** Bug 147206 has been marked as a duplicate of this bug. ***
Comment 3 Björn Ruberg 2009-12-24 15:17:04 UTC
Is this still a problem in KDE 4.3?
Comment 4 Wolfgang Rohdewald 2013-03-03 22:45:36 UTC
I am quite certain that this should work flawlessly with KDE 4.10.1, to be released this tuesday. Probably also with 4.10.0.

If nobody objects within the next 7 days, I will close this bug report.