GNOME Bugzilla – Bug 627952
'Local delivery' mbox's aren't read properly
Last modified: 2013-09-13 01:04:23 UTC
This is actually part of bug 625351 (see comment #4 and onwards), but seems to have fallen through the cracks since it was determined that the rest of that bug was a gtk+-3.0 issue. This isn't. In short: I use procmail to filter incoming spam and/or viruses and suspicious mail is put into two files in ~/Mail/Inbox.{spam,virus} on my computer. I have set up Evolution (the git/master) to have 2 mbox accounts (configured with local delivery) for these files. Since the migration to .local/share/evolution (which, here, also corresponded to switching to gtk+-3.0, which has been reverted) I've noticed that these folders (in evo) never have anything in them. Worse, once evolution updates its folders, the disk files are empty (which is what should happen), but again nothing appears in evo's folders and it seems that the mail is lost. I've checked that the files have mail in them before running evolution. Some other observations: 1. The current evolution (the git/master from yesterday) shows the mbox as a separate account in the folder list. In the past it was a subfolder of "On this computer" or didn't appear at all (I think). 2. I have a filter that moves incoming mail from these "Source Account"s into other folders. I'd thought that this might be the source of the problem, namely, the data was being deleted before the filter finished, but having this filter active or not has no effect on the bug. 3. I have deleted the accounts and recreated them; the problem remains. 4. The only console output that is remotely relevant is: (evolution:1566): camel-WARNING **: CamelMboxStore::get_folder_info() reported failure without setting its GError
I suspect the message filter rule being the case, and maybe, after some rewrite, the enabled part doesn't work. What is your message filter exactly, and what is it expected to do, please? I tried with some simple mbox files, but even I have there a filter of "if source account is xxx, them move to On this computer/inbox/spam" then it is not applied automaticly, though I have this option checked in mbox account preferences. And the Ctrl+Y works. Might be something on my side, I suppose.
Hrm, I'm too quick in writing. Filters are still not applied to my messages there, but if I add to the mbox file a new message (with a new messageID), then I see on console: > camel-local-provider-WARNING **: The next message didn't start where > I expected, building summary from start and I see an attempt to apply junk checking on the new message, with 3 unread count on the mbox file's "Inbox", but no content in it. But the next start I see the content as expected, so it seems that for me the summary rebuild makes things strange. It's a different issue from yours, because may be close enough. My question about your filter setting for the mbox file still applies. Also, how is it you expect these folders being empty after filter processing? Do you have also real files content being zero length? I would expect those messages being marked as Junk or Deleted, thus visible in Junk or Trash folders in the mbox file account, but the whole file content being erased sounds pretty strange to me.
Hi Milan, Couple of things. First, the filter is as you described. If source account (an mbox in my ~ tree) move to special folder. The problem arises with or without the filter enabled. Part of the problem is that I don't always see a folder for the account in the folder list. Specifically, when I fire up evolution, the folder/account list in the mail doesn't show the account. However, if I use preferences to toggle the account on and off, the account shows until I restart evolution.
One more thing. I don't have junk checking enabled as a default. (procmail does it for me as the mail comes in--turns out it leads to much faster startups).
(In reply to comment #3) > Couple of things. First, the filter is as you described. If source account > (an mbox in my ~ tree) move to special folder. The problem arises with or > without the filter enabled. I might suspect something about the filter doesn't work (maybe the enable/disable part as well). Please make sure the filter points to a correct folder, as it is reachable and writeable. Maybe it fails but to copy routine doesn't notice it, and thinks it was moved, thus deletes the message. I guess I may write a debug patch to see what it actually does. > Part of the problem is that I don't always see a > folder for the account in the folder list. Specifically, when I fire up > evolution, the folder/account list in the mail doesn't show the account. > However, if I use preferences to toggle the account on and off, the account > shows until I restart evolution. Hmm, I never saw this, maybe some timing issue or something, hard to tell.
Created attachment 169550 [details] eds debug patch for evolution-data-server; Please try with this patch applied. It does basically nothing, only prints some (I hope) useful messages on console about what it does while filtering and when it expunges mbox. Before you run this, please backup your ~/Mail and also ~/.local/share/evolution/mail/spool/ folders, so we'll be able to reproduce this fully, without much effort. (I suppose you'll have there some messages to be filtered.)
Confirming. After our chat on IRC I see it too. The main difference is to use Server Type "Local Delivery", there the messages are lost. I realized they were properly moved to ~/.local/share/evolution/mail/spool/movemail.mbox... and from there they weren't moved to On This Computer/Inbox.
Created attachment 169590 [details] [review] evo patch for evolution; It's this simple. The routine thought the mailmove failed, so it didn't process messages further. With respect of "Once the account is shown in the folder tree, after restart it isn't", I believe it's correct. You mentioned you didn't see it in the folder tree earlier too.
Created commit 13241ca in evo master (2.31.92+)
I've reopened this. The current git master (3.1 as of last night) seems to have this problem again.
Created attachment 187273 [details] [review] evo patch for 3.1.0 for evolution; Good catch, it's only for 3.1.0, after commit 397aeade, which was done on the 21st.
Created commit 19a9f34 in evo master (3.1.1+)
I updated to the git master yesterday. I'm again having this problem. My file ~/Mail/Inbox.Spam has lots of junk in it, but it's stopped being delivered to the appropriate on this computer folder. This worked last week. (I think) I'm reopening the bug.
Created attachment 200390 [details] [review] evo patch (3.3.1) for evolution (3.3.1); This is similar brokenness, but a very different issue. I suppose you edited your account or something? Maybe a pseudo-migration failed as well. With the editor there is an issue that camel_settings_save_to_url() rewrites updated values, thus I'm returning them back in this patch - with it it works as expected, thus maybe you'll need to re-setup your Local delivery account setup.
Created commit ea8d9ff in evo master (3.3.2+)
Matthew, please, create a 'Local delivery' account and make sure your account changes will actually work with them too, same as with other local providers, because I'm quite unhappy of fixing this each cycle, after certain changes on things which used to work properly. Thanks in advance. (Note that I'm not going to touch this bug any more, 3 times is really enough.) David, please, open new bug reports for new versions - if needed, each fix was a different issue, in a different version, we cannot do this all in one single bug report, dating back to 2.31.x. Thanks for your understanding.
(In reply to comment #16) > Matthew, please, create a 'Local delivery' account and make sure your account > changes will actually work with them too, same as with other local providers, > because I'm quite unhappy of fixing this each cycle, after certain changes on > things which used to work properly. Until 'Local delivery' accounts are adequately commented in the source code, I imagine they will continue to break whether by my hand or others'. For example the patch you just committed has zero comments explaining the strange looking URL workaround or why it's needed.
Hi Milan, I applied the patch and rebuilt. It still doesn't work. I tried also modifying the account settings and added another local delivery account. Finally, I was trying to edit my default account (all in the same evolution session) when evo crashed. Here's the backtrace: Core was generated by `evolution'. Program terminated with signal 11, Segmentation fault.
+ Trace 228961
Thread 1 (Thread 3814)
Finally, after the current problem is fixed, I'll start a new bug report the next time this happens.
The problem seemed to be in the <url> for the account. Basically it had: mbox:/home/ronis/Mail/Inbox.Spam; path=/usr/local/ The path is wrong, but manually deleting it using gconf-editor fixes the problem.
(In reply to comment #17) > Until 'Local delivery' accounts are adequately commented in the source code, I > imagine they will continue to break whether by my hand or others'. For example > the patch you just committed has zero comments explaining the strange looking > URL workaround or why it's needed. My point is that any change in account-management rewrite may not break any current feature of evolution. Ideally. The committed patch only workarounds breakage you caused with the commit to the "path" and CamelLocalSettings, which landed too early. I expect you'll drop most of this patch when you'll be merging your branch into master. (In reply to comment #18) > Hi Milan, > > I applied the patch and rebuilt. It still doesn't work. I tried also > modifying the account settings and added another local delivery account. > Finally, I was trying to edit my default account (all in the same evolution > session) when evo crashed. Here's the backtrace: > > Core was generated by `evolution'. > Program terminated with signal 11, Segmentation fault. The patch is fixing crash I faced myself, incorrect call of camel_provider_get(), earlier in the crashing function. I suppose the provider wasn't found, and it's the reason why it crashed. If you can reproduce even after your manual fix of the url in gconf, then please file a new bug report for it and CC me there. Please provide these prints in the crashing thread from gdb in the bug report: (gdb) p url (gdb) p *url (gdb) p service->provider Thanks in advance.