[kmail2] [Bug 358512] New: false importing of mail - kmail2 akonadi bug

[Andrew via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358512

            Bug ID: 358512
           Summary: false importing of mail - kmail2 akonadi bug
           Product: kmail2
           Version: 4.14.3
          Platform: FreeBSD Ports
                OS: FreeBSD
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: general
          Assignee: kdepim-bugs at kde.org
          Reporter: daeron at optushome.com.au

Kmail2 gives a false report that it has finished importing mail.
** Other unexplained bug reports about mail disappearing could be related to
this systemic bug.
  The illusion is that Kmail2 has imported your mail into your mail directory,
when it has in fact moved it to the akonadi database which may or may not
succeed in exporting your mail or some of your mail to your mail diretory over
the next few hours or days.   The result is that people can & do lose some or
all of their mail if either the process or the database are disrupted before
the slow process is finished.

Reproducible: Always

Steps to Reproduce:
1. Have over 1 gb email in a non-kmal folder or mbox
2. import the import mail

Actual Results:  
Kmail2 import functions move your email onto the akonadi database instead of
your mail directory. Also as Kmail2 puts your email in jeopardy on the akonadi
database, the import dialogue tells the user/victim that 100% of the mail has
been imported and that the importing is finished. For hours or years afterwards
your system becomes unresponsive and clogged up with unexplained akonadi
activity while your email remains in jeopardy and will disappear if either the
process or database are disrupted.

Expected Results:  
Kmail2 imports email to your mail directory.
If importing mail requires a temporary staging area, that it would use /tmp and
NOT a database!

This appears to be another example of children wanting to use databases for
things that should not be on a database. Its arogance to assume previous
programers decided against using databases because they failed to understand
how fast databases can be; with experience you too may learn that things like
configuration & storage files should be kept on disc and not in a database that
is open. It's been going on since the 1980s, people design good systems and
then next generation of programers foul it up with inappropriate databases.
Databases are great in their place and a menace outside it.

-- 
You are receiving this mail because:
You are the assignee for the bug.