Bug 3293 - Sometimes imapcache produces wrong email contents
Summary: Sometimes imapcache produces wrong email contents
Status: NEW
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Folders/IMAP (show other bugs)
Version: 3.10.1
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2014-09-28 10:03 UTC by Pekka Paalanen
Modified: 2015-10-19 09:48 UTC (History)
4 users (show)

See Also:


Attachments
Screenshot of confilcting message information (272.22 KB, image/png)
2014-09-28 10:03 UTC, Pekka Paalanen
no flags Details
output of claws-mail --debug, corresponds to screenshot (75.45 KB, text/plain)
2014-09-28 10:09 UTC, Pekka Paalanen
no flags Details

Description Pekka Paalanen 2014-09-28 10:03:52 UTC
Created attachment 1433 [details]
Screenshot of confilcting message information

I have several accounts configured in claws-mail, one of them is IMAP for gmail. At some point during the last few months I noticed the imapcache starting to sometimes produce wrong content.

The screenshot describes the problem, let's take the "From" field as an example:
- in the email list, the highlighted item is from Emil.
- in the integrated message view, the heading (on gray background) says from Emil.
- in the integrated message view, the content says from Kenneth (incorrect!)
- in the separate message window, the heading says from Emil.
- in the separate message window, the content says from Kenneth (incorrect!)

The email body is from a wrong email, not the one I chose/opened in the list.

I opened the separate message window to assure you that simply clicking on the email list does update the integrated message view. (I seem to recall another similar bug report, where you suspected the GUI was simply configured to not update the message view on simple click in the list.)

When I notice wrong email content, I quit claws-mail, do 'rm .claws-mail/imapcache/imap.gmail.com/ppaalanen\@gmail.com/lists/mesa-dev/*', and restart claws-mail. This is needed to make the email content appear correctly.

I am accessing the gmail via IMAP from two separate machines (independent claws-mail installations), but the two claws-mail instances are never running simultaneously. The problem can happen in both instances.

I also have automatic processing rules in both installations for the gmail Inbox, which moves messages from Inbox to e.g. mesa-dev folder. The processing rules are not identical between the two installations.

The version of claws-mail is 3.10.1 as from Gentoo official packages mail-client/claws-mail-3.10.1.
Comment 1 Pekka Paalanen 2014-09-28 10:09:47 UTC
Created attachment 1434 [details]
output of claws-mail --debug, corresponds to screenshot

Here is a claws-mail --debug output, when producing the situation in the screenshot.

However, the chosen email in the screenshot was already giving wrong content before starting this debug session, so the debug log probably does not contain how the bad cache content came to be in the first place.

I cannot reliably predict when or which email will hit the problem. It does not happen for all emails arriving in the same batch or whatever, but appears to be a more random per-message thing.
Comment 2 Paul 2014-09-28 10:12:40 UTC
(In reply to comment #0)

> When I notice wrong email content, I quit claws-mail, do 'rm
> .claws-mail/imapcache/imap.gmail.com/ppaalanen\@gmail.com/lists/mesa-dev/*',
> and restart claws-mail. This is needed to make the email content appear
> correctly.

You can also open the folder Properties and click the 'Discard folder cache' button.
Comment 3 Pekka Paalanen 2014-09-28 10:22:42 UTC
(In reply to comment #2)
> You can also open the folder Properties and click the 'Discard folder cache'
> button.

Ah, thanks, that's easier than 'rm'. I didn't realize to look for that in the Properties dialog, I only looked at the context menu. That works.

Hmm, except it triggers a re-download of the whole folder (just headers?), and having tens of thousands of emails there makes it take a long time.

Doing the 'rm' trick however does not cause the long download. It will only re-download the messages I actually open. Rm does not remove the dot-files.
Comment 4 Pekka Paalanen 2014-10-04 12:38:26 UTC
I seem to be suffering from this on a daily basis at home (one claws-mail installation) even when I do not use it at work (the second claws-mail installation) in the mean time. It happens at work too, but I feel it is more rare.

I suspect it might be related to the automatic processing rules I have set on my Inbox, which move mailing list emails into respective folders. And gmail. At work I have another IMAP account set up too that is not gmail, also with automatic processing rules, but I have never seen it have this problem, although it also has much less traffic.
Comment 5 Christian Weiske 2014-10-07 13:46:50 UTC
I face the same problem with 3.10.1 on Ubuntu 14.04.
Comment 6 ygrek 2014-10-18 10:43:03 UTC
This happens for me too and reproduces with 100% probability under the following conditions :

- IMAP account on gmail server (didn't check with other servers)
- receiving several messages at once (essential)
- automatic filtering rule on receive that moves several of freshly received messages to another folder (essential)

At this point of time (if messages are not clicked) the files in imapcache have correct content, but at the time of opening claws overwrites one file with the content of another.

Result: both of the new messages show correct line in summary view, but have the same exact content after clicking on them.

Discarding folder cache or manually removing the files with wrong content from the imapcache fixes the issue (both new messages show correctly).

Bug only happens with automatic filtering on receiving, manual filter without receiving behaves correctly.
Comment 7 Christian Weiske 2014-10-18 18:57:17 UTC
I have the problem with manually moving mails into folders, without any filters.
But I cannot reproduce the problem with certanity; it happens with about 1 of 50 mails.
Comment 8 Pekka Paalanen 2014-11-23 09:24:12 UTC
While working with 3.10.1 at home, and 3.9.0 at work, I have got the impression, that 3.10.1 causes the content confusion a lot more often (maybe every time the automatic processing rule moves a bunch of email from inbox to another IMAP folder) than 3.9.0.

I haven't rigorously verified it, but it seems like I am rm'ing the cache on 3.10.1 every time I want to read moved email, and with 3.9.0 only rarely. This obviously makes me reluctant to consider upgrading the 3.9.0 until this issue gets fixed.
Comment 9 Paul 2014-11-23 10:07:22 UTC
(In reply to comment #8)
> While working with 3.10.1 at home, and 3.9.0 at work

The latest release is v. 3.11.1, what can you observe with that?
Comment 10 ygrek 2014-11-23 10:27:23 UTC
I am running 3.11.1 and it happens as described in comment #6
Comment 11 linux+clawsbugtracker 2014-12-19 01:02:15 UTC
I am also seeing this problem in recent versions of claws, including 3.11.1 on ubuntu trusty installed from the ppa.

This problem is NOT limited to gmail, as this happens with a completely unrelated imap server for me. Furthermore, the relevant inbox is accessed from a single claws-mail install only, and not used by any other means (i.e. webmail or mobile phone) yet the bug still happens.

Other than that, I can confirm most of what is said in prior messages, esp. #6. The bug seems to be triggered when receiving messages that are moved into a subdir by a filtering rule. It is irrelevant whether or not the filtering rule also marks the message as read.

Everything appears normal in the summary view at first glance, but upon opening any email the message body displayed may be (a copy of) a different message not matching the subject/sender as visible in the summary view. Opening the 'source view' for an affected email displays the actual subject/sender/etc matching the initially displayed message body.

Not all messages are broken, but it happens often enough for daily problems even on a moderate amount of traffic (e.g. debian mentors mailing list). Discarding the folder cache indeed works as a (temporary, and slow) workaround, at least until the next round of new mail arrives.
Comment 12 linux+clawsbugtracker 2015-10-07 22:12:16 UTC
Still happens with 3.12.0
Comment 13 Lars Wendler 2015-10-08 09:07:48 UTC
I have the same problem although not with an imap folder but with an mbox folder where a rule is moving spam mails in.
This makes it quite hard to find false positive spam mails.
Comment 14 Andrej Kacian 2015-10-10 15:09:21 UTC
I think the problem might be caused by our using chdir() a lot, which could be a problem with multiple threads.
Comment 15 Pekka Paalanen 2015-10-19 09:48:12 UTC
(In reply to comment #14)
> I think the problem might be caused by our using chdir() a lot, which could
> be a problem with multiple threads.

That could certainly explain why I also get hundreds of

/home/pq/.claws-mail/imapcache/imap.gmail.com/ppaalanen@gmail.com/INBOX/123734: unlink: No such file or directory

often when I close claws-mail. I haven't noticed anything bad happening from that, so I never reported it.

This is just an anecdote, and perhaps off-topic.

For the record, I have "Metadata handling" set to "Safer", and I'm using spinning disks on laptops which means disk ops are not too fast. Maybe that contributes here?

Note You need to log in before you can comment on or make changes to this bug.