Bug 287394 - KMail2 with fetchmail/postfix-fed mbox resource: can't get rid of "changed by another program" alerts
Summary: KMail2 with fetchmail/postfix-fed mbox resource: can't get rid of "changed by...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: MBox Resource (show other bugs)
Version: 4.12
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-23 20:07 UTC by anj.tuesday
Modified: 2017-01-07 22:48 UTC (History)
3 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 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.