Bug 290013

Summary:	Kmail2 does not mark system messages as read, deleted, etc
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Eric Mesa <ericsbinaryworld>
Component:	MBox Resource	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	amantia, quazgar
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Eric Mesa 2011-12-28 14:04:27 UTC

Version:           unspecified (using KDE 4.7.3) 
OS:                Linux

I have Kmail2 setup to check my system messages (the ones you get from cronjobs or logwatch).  With Kmail 1 this worked perfectly.  With Kmail2 when I mark a message as read or deleted, the next time that folder refreshes the message is once again marked as new.  So while I can use Kmail2 to read these messages, I need to use mutt to actually delete them or mark hem as read.

Reproducible: Always

Steps to Reproduce:
1. Check system messages
2. Delete messages after reading
3. Refresh system messages 
4. Messages are back and marked as new

Actual Results:  
The messages appear again marked new

Expected Results:  
Deleted messages should be removed from the system.  Messages marked read should stay marked read.

This is on Fedora 16 with the following kdepim package:  http://lists.fedoraproject.org/pipermail/package-announce/2011-December/071186.html  I'm not in front of the computer right now, but I know I applied this update.  So I'm using whatever versions of Kontact/Kmail2 are in there.

Comment 1 Torgny Nyblom 2012-01-04 19:27:51 UTC

What kind of resource is this (mbox/maildir/mixed/...)?

Comment 2 Eric Mesa 2012-01-05 01:25:08 UTC

It's MBox

Comment 3 Torgny Nyblom 2012-01-05 10:35:46 UTC

Whats is the permissions on that mbox file and what (if any) is written on the console while reading one such mail (preferably both from akonadi and kmail)?

The akonadi output can be obtained by starting akonadi in a terminal, "akonadictl restart" and waiting for the output to settle down (might take a while).

Comment 4 Eric Mesa 2012-01-06 11:52:46 UTC

The permissions are: 

-rw-rw----.with myself as owner and mail as group owner.

I click on the email and I get:
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)" 
kontact(9517): Error while fetching items.  103 "Unknown error. (Cannot list root collection.)"
(that's the output of Kontact in the commandline)

But that only happens on the first email.  All the others display without errors.  And there are no errors as I delete them.  But as soon as I go in and out of mutt, they call come back.

Let me see akonadi.  

Here's me accessing the mail:

request for item 411285 succeeded 
void Nepomuk::Query::QueryServiceClient::close() 
void Nepomuk::Query::QueryServiceClient::close() 
AkonadiAgentServer(9812)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/var/spool/mail"

This comes up when I delete it:
posting retrieval request for item 411286  there are  1  queues and  0  items in mine 
request for item 411286 still pending - waiting 
processing retrieval request for item 411286  parts: ("RFC822")  of resource: "akonadi_mbox_resource_0" 
continuing 
request for item 411286 succeeded 
AkonadiAgentServer(9812)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/var/spool/mail" 
void Nepomuk::Query::QueryServiceClient::close() 
void Nepomuk::Query::QueryServiceClient::close() 
AkonadiAgentServer(9812)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/var/spool/mail"

And that happens every time I try to delete one.

Comment 5 quazgar 2012-02-05 16:29:47 UTC

Probably a duplicate of bug #278887 ?

Comment 6 Eric Mesa 2012-05-03 17:25:50 UTC

yeah, I'm ok with calling it a duplicate

*** This bug has been marked as a duplicate of bug 278887 ***