Bug 278887 - Mbox resource never deletes email
Summary: Mbox resource never deletes email
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: MBox Resource (show other bugs)
Version: 4.7
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 257017 282630 290013 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-30 20:31 UTC by auxsvr
Modified: 2017-01-07 22:11 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description auxsvr 2011-07-30 20:31:58 UTC
Version:           4.7 (using KDE 4.7.0) 
OS:                Linux

The emails I delete from the local mbox account in kmail are never deleted from the mbox file, only adding emails to them works. Something that might be related is that occasionally an error message about another program editing the mbox appears and suggests the use of locking. However, the error message appears whether locking is enabled or not.

Reproducible: Always

Steps to Reproduce:
Try to remove emails in kmail from an mbox resource. Even after syncing, waiting for the CPU to become idle and restarting akonadi the emails remain in the mbox file.

Actual Results:  
The emails persist in the resource, even though kmail shows that they are deleted.

Expected Results:  
The emails are removed from the mbox file.

This is important to me, because the migration utility unfortunately configured kmail to expire 10k of emails and send them to the mbox...
Comment 1 Matti Kettunen 2011-08-01 10:24:32 UTC
KMail doesn't change message status either. Everytime new message arrives KMail informs that all the messages in mbox are unread.
Comment 2 P. Varet 2011-10-19 12:08:17 UTC
Confirmed here too. How can this have shipped?

No workaround found, using mutt until this is fixed.

Further details: when KMail tries to refresh the local mbox, I get three notifications. Two of them say:

"Local Account: The MBox file was changed by another program. A copy of the new file was made and pending changes are appended to that copy. To prevent this from happening use locking and make sure tha…"

Yes, the notification message is incomplete. :/

The last notification says:

"Local Account: The file 'file:///var/mail/sundance' was changed on disk while there were still pending changes in Akonadi. To avoid data loss, a backup of the internal changes has been created at 'file:///home/su…"

One of the notifications suggests using locks but all the lock options in the settings for this account are greyed out. Besides, Akonadi is the only program accessing the file at the time... So it seems it's competing with itself for access to the mbox!

This is discouraging. :(
Comment 3 quazgar 2012-02-05 16:10:49 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 quazgar 2012-02-05 16:21:06 UTC
Confirmed for 4.7.4.

I also noticed (this may or may not be related) that "file monitoring" must be enabled for kmail to find any mails in the mbox file at all.
Comment 5 quazgar 2012-02-05 16:56:05 UTC
Setting the compacting frequency to 1 (every message) might work around this bug. This does not change the fact that messages do not seem to be marked for deletion, but at least they are actually deleted immediately.
Comment 6 anj.tuesday 2012-02-06 21:46:36 UTC
*** Bug 282630 has been marked as a duplicate of this bug. ***
Comment 7 Eric Mesa 2012-05-03 17:25:50 UTC
*** Bug 290013 has been marked as a duplicate of this bug. ***
Comment 8 Martin Koller 2015-01-31 22:55:55 UTC
*** Bug 257017 has been marked as a duplicate of this bug. ***
Comment 9 Denis Kurz 2016-09-24 20:34:20 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 10 Denis Kurz 2017-01-07 22:11:05 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.