Bug 752243

Summary: kmail resource conversion to akonadi: process is very unclear
Product: [Fedora] Fedora Reporter: Piotr Golonka <piotr>
Component: kdepimAssignee: Than Ngo <than>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: jreznik, juha.heljoranta, kevin, ltinkl, markku.kolkka, rdieter, rnovacek, smparrish, than, umar
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 23:19:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Piotr Golonka 2011-11-08 22:38:03 UTC
Description of problem:

Upon the first startup of kontact/kmail, a migration of resources (to akonadi) is performed. The dialog box tells that this may take a long time, and closes. 
In my setup, I had a number of local mail folders (used before with KMail from Fedora 14), plus the IMAP folder; the migration of IMAP was quite fast, reliable, and self-explanatory (the progress dialog cleanly said that the conversion was finished). Then, when it started to migrate the local folders, all that I saw was 100% CPU consumption, and the list of my local folders under "KMail Folders". However, all the folders seemed to be empty (!)

After some investigation I realized that after selecting "Update Folder" from folder's context menu, the contents start to appear. Actually, to perform the update on all folders, one could select "Update folder and its subfolders" for the "KMail Folders", so that all the subfolders are updated.

This step should have been performed automatically by the resource-conversion script, and the progress of this (timely! taking tens of seconds per folder) process should be clearly presented to the user.

Version-Release number of selected component (if applicable):

Kmail 4.7.2, kdepim-4.7.2-5.fc16.x86_64

How reproducible:

The problem occured twice, on the two machines that I upgraded from F14 to F16, i.e. 100% reproducible for me

Steps to Reproduce:
1. Create local email folders in Kmail on F14; put a couple of thousands of emails into them (~100 MB per folder)
2. Upgrade to F16
3. Start kmail, approve the migration, look at the CPU consumption and contents of folders.
  
Actual results:

Folders are empty; 100% CPU load (namely due to mysqld and akonadiserver); no information about the progress of migration whatsoever.

Expected results:

A progress of conversion process should be shown in a window, allowing to
break it, and explaining that the local "maildir" folders could later be imported through kmail's File->Import Messages

Additional info:
The conversion could probably succeed if done by a Linux and KDE-savvy person. For (an impatient) non-expert the migration to F16 may seem to be catastrophic ("I lost all my historical email stored in my kmail folders"). A potential serious blow for existing users.

Comment 1 Sammy 2011-11-15 15:58:52 UTC
I am having the same thing except my folders ARE ALWAYS EMPTY choosing the option
"Update Folder" is not bringing anything. The files seem to be there and the
directory name in settings is correct.HELP!

Comment 2 Markku Kolkka 2011-12-08 11:26:35 UTC
(In reply to comment #1)
> I am having the same thing except my folders ARE ALWAYS EMPTY choosing the
> option
> "Update Folder" is not bringing anything. The files seem to be there and the
> directory name in settings is correct.HELP!

Same situation here, "migration" creates the folder names, but all folders remain empty. New install (not upgrade) of F16 while keeping the old /home volume.

Comment 3 Rex Dieter 2011-12-08 13:08:21 UTC
bugzilla is here for reporting bugs, and isn't all that great a forum for technical support per-se (ie, asking "HELP!" here is usually an unrealistic expectation).  That said, yes, migration from kmail1 content is a known-weak area of kmail2(aka kdepim-4.6+) at the moment unfortunately.  

I'd recommend following up on 
https://mail.kde.org/mailman/listinfo/kdepim-users
a more ideal forum to share your experiences, and hopefully find a more satisfying resolution.

Comment 4 Piotr Golonka 2011-12-08 14:12:36 UTC
Hello Rex,

If you considered this as a rant rather than a bug report - sorry. It was definitely not my intent. I'm trying to become useful to Fedora community by filling bug reports and giving feedback about problems that other people also encounter (no, I do not need help, and no, I do not need technical support; I know how to salvage myself after 15 years of being a diehard fan if RedHat/Fedora and KDE).

cheers and keep Fedora rocking,
 Piotr

Comment 5 Juha Heljoranta 2011-12-10 21:05:48 UTC
I managed to make it work. 

0. backup (~/.kde and ~/.local)
1. stop akonadi and close kmail
2. delete index files under kmail/mail dir:
   $ find ~/.kde/share/apps/kmail/mail -name '*index*' -delete
3. move mail dir to local-mail:
   $ mv ~/.kde/share/apps/kmail/mail/* ~/.local/share/.local-mail.directory/
4. delete akonadi data files:
   $ rm -rf ~/.local/share/akonadi
5. start akonadi

Removing the akonadi datafiles will trigger re-import when you try to access your emails next time. Note that importing can take a long time if you have lot of emails...

Problem seems to be that "kmail maildir" akonadi resource type doesn't work at all (at least for me). Using plain "maildir" akonadi resource type works but requires erasing all akonadi data.

akonadi console was a great help while debugging this issue.

Comment 6 Fedora End Of Life 2013-01-16 19:31:38 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Fedora End Of Life 2013-02-13 23:19:10 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.