Bug 285843

Summary: kmail2 importing process doesn't correctly detect read/unread status flag
Product: [Applications] kmail2 Reporter: Fabio Rossi <rossi.f>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: karl, kollix
Priority: NOR    
Version: 4.7   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:

Description Fabio Rossi 2011-11-05 18:54:20 UTC
Version:           4.7 (using KDE 4.7.3) 
OS:                Linux

I'm migrating from kmail1 to kmail2 trying to import the maildir with the provided tool kmailCVT. As stated in #133210 kmail1 stores the read/unread status in its indexes files for speed reasons and it doesn't keep updated the mail files. The import procedure reads only the plain mail files so the status is wrong not considering the indexes! 

I guess the result is similar for the other flags.

Considering that the data is produced by kmail1, this is a bad problem because kmail2 can't read correctly its predecessor files.

Reproducible: Always

Steps to Reproduce:
import a maildir structure produced by kmail1

Actual Results:  
the read/unread status is read from the mail files and not from the indexes

Expected Results:  
The import process should preserve the read/unread status flag.
Comment 1 Martin Koller 2012-07-21 20:50:07 UTC
Still correct with KDE/4.9
But you can add a maildir account pointing to the maildir directory (without copying the mails as the import does) and this maildir resource keeps the read/unread status.
Comment 2 Denis Kurz 2016-09-24 17:54:13 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 3 Denis Kurz 2017-01-07 22:23:19 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.