Bug 287394

Summary:	KMail2 with fetchmail/postfix-fed mbox resource: can't get rid of "changed by another program" alerts
Product:	[Frameworks and Libraries] Akonadi	Reporter:	anj.tuesday
Component:	MBox Resource	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	Christoph.Pospiech, kollix, martin.schnitkemper
Priority:	NOR
Version:	4.12
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description anj.tuesday 2011-11-23 20:07:04 UTC

Version: unspecified (using KDE 4.7.2)
OS: Linux

I use fetchmail and postfix to regularly retrieve mail from a number of POP accounts; it ends up in /var/mail/username. I also have an Akonadi mbox resource pointed at that file so I can easily get at new mail with any random email client I might want to try.

This works fine with Thunderbird or Evolution as well as console mailers like Alpine... and it has worked fine in the past with pre-Akonadi KMail.

But now Akonadi and/or KMail pop up four notifications every time I receive mail to complain that file:///var/mail/username has been changed by another program and that a backup has been created. Isn't it *supposed* to be changed by another program? How else would it receive email?

I can turn off file monitoring for the Akonadi mbox resource, but then KMail never finds any new email any more.

Reproducible: Always

Steps to Reproduce:
Set up fetchmail and postfix to stuff mail retrieved from POP accounts into /var/mail/username.
Create an Akonadi mbox resource and point it at this same file.
Receive new mail.

Actual Results:
Mail appears in KMail in the folder representing the mbox resource, but there're one notification popup "username" + three identical notification popups complaining that file:///var/mail/username has been changed by another program and that a backup has been created. Turning off file monitoring means no more new email is seen in KMail.

Expected Results:
Mail should appear in KMail in the folder representing the mbox resource, without warnings, considering this is perfectly normal use of email software (...it is, yes?)

Comment 1 Dr. Christoph Pospiech 2011-12-31 20:54:03 UTC

Hi,

I had the same problem and just found a very simple solution (you may call it a work around).
Prerequisites - I am using postfix and procmail for mail delivery. Actually, I have a fetchmail type client that funnels incoming mail through procmail.
HOWTO implement - 
step1 * If not already done, add the line 
mailbox_command = /usr/bin/procmail
to /etc/postfix/main.cf and restart postfix.
step2 * If ~/.procmailrc doesn't exist, create this file with the following contents.
LOGFILE=<your_choice_of_logfile_name>
VERBOSE=yes

:0 :<your_choice_of_lock_file_name>
<your_$HOME>/.local/share/Linux-mail/
!!! And don't forget the '/' after 'Linux-mail' !!!
step3 * send a test mail to your account, procmail will create new, cur and tmp
sub directories in <your_$HOME>/.local/share/Linux-mail/ as needed.
step4 * Open kmail2, Settings->Konfigure kmail->Accounts->receiving and add
a new akonadi resource of type maildir, pointing to 
<your_$HOME>/.local/share/Linux-mail
step5 * wait some time for akonadi and kmail2 to recognize this new resource.
You will find your new mail right there - and NO more "changed by another program" alerts.

Have fun ! Christoph Pospiech

Comment 2 Martin Schnitkemper 2014-04-23 20:14:55 UTC

I can confirm this problem.  It worked well until kde-4.12.4 but after upgrading to kde-4.13 I get also always the "changed by another program" alert upon every new mail delivered by postfix.
If I set up Akonadi again as suggested at http://docs.kde.org/stable/de/kdepim/kmail/clean-start-after-a-failed-migration.html it works well for a few days, and then the problem appears again.

Comment 3 Denis Kurz 2016-09-24 20:36:09 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 4 Denis Kurz 2017-01-07 22:48:44 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.