Bug 290013 - Kmail2 does not mark system messages as read, deleted, etc
Summary: Kmail2 does not mark system messages as read, deleted, etc
Status: RESOLVED DUPLICATE of bug 278887
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: MBox Resource (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-28 14:04 UTC by Eric Mesa
Modified: 2012-05-03 17:25 UTC (History)
2 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 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 ***