[Bug 294513] New: Kmail2 migrator destroyed existing mail base despite being told to cancel and not proceed

[Gulraj Rijhwani]

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

           Summary: Kmail2 migrator destroyed existing mail base despite
                    being told to cancel and not proceed
           Product: kmail2
           Version: 4.8
          Platform: Fedora RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: general
        AssignedTo: kdepim-bugs at kde.org
        ReportedBy: gdr-kde at courtfields.com


Version:           4.8 (using KDE 4.8.0) 
OS:                Linux

Having migrated Kmail 1.8 (most recently) mbox style mailbase (directories,
mbox files, local static indexes) to a Fedora 16 box with KDE 4.7.4 as
standard, and having already encountered similar problems (when the Akonadi
helper just ran away with memory until the kernel assassinated it) when
upgrading another box from Fedora 14 to 16, I replaced KDE 4.7.4 with KDE 4.8.0
from the fedora-kde48 repo as advised on here.

On first and only run of kmail it advised me that it needed to migrate to the
Akonadi storage model as expected from previous experience.  Realising the
catastrophe the last attempt had been, and further that I had not yet backed up
the .kde directory, I told the process to cancel, only to find that it appears
to have already part trashed the existing mailbase by replacing part of the
mbox hierarchy with empty maildir directories.

No, I don't have a back trace (there was none).  Yes, I was running the latest
release.

Purely as a PS, I find myself asking how did this piece of (expletive) make it
into a supposedly "stable" release when it does not (and akonadi and its
accompanying helper, and even kmail2 don't) seem to even understand mbox format
files any more?  I have said it before, Akonadi and all its overheads, were a
wrong choice all along.  KDE used to integrate perfectly well without it.  5
years down the line and KDE4 STILL has not got the simple interworking, and
efficiency that it once had working with open standard format flat files and
simple APIs.

Reproducible: Didn't try

Steps to Reproduce:
Start kmail2 on an unmigrated kmail1 mailbase.  Whether this particular quirk
is reproducible I know not.

Actual Results:  
Mailbase trashed.

Expected Results:  
Kmail2 running with same pre-existing mbox folder hierarchy, or following a
cancel instruction - as in this case - no action taken.

I have inferred - looking at wider problems with the migration process because
sooner or later I would like to be able to get back into my mail from the last
5 years - that at present kmail/Akonadi are completely ignorant of mbox format
files.  When started on a virgin mailbase kmail does not offer the option to
create mbox style directories, and Akonadi's memory runaway suggests an attempt
to digest 2GB mail files as single messages.  As to the cause of this behaviour
problem - overwriting the mailbase despite explicit instructions to take no
action - I have no further information.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.