[Kde-pim] migrating from KMail1 to KMail2 (and back?)

[Kevin Krammer]

On Thursday, 2010-06-17, Sebastian Kügler wrote:
> Hi,
> 
> [readding opensuse-kde list in CC:]
> 
> On Thursday 17 June 2010 13:52:29 Kevin Krammer wrote:
> > On Thursday, 2010-06-17, Sebastian Kügler wrote:
> > > On Thursday 17 June 2010 13:22:39 Kevin Krammer wrote:
> > > > On Thursday, 2010-06-17, Sebastian Kügler wrote:
> > > > > - Is the migration process destructive, so after migration, the
> > > > > KMail1 config + cached data is gone?
> > > > 
> > > > The migration process itself is only destructive on the user's
> > > > choice. I.e. when migrating disconnected IMAP accouts, users are
> > > > presented with the option to either keep the old cache or deleting
> > > > it after import.
> > > 
> > > Alright, I understood that (roughly) from your other emails on this
> > > subject. What is the default here?
> > 
> > This is a question message box with two options, delete old cache being
> > the  active/default button, ESC triggering "keep".
> > I could add another config option to not ask but always keep though.
> 
> Is this per folder? (I have 60 folders, and I'm sure some of the audience
> here has even more. That might result in an exercise in RSI if I have to
> check something for every migrated folder (and I can't make up valid
> enough use- cases where you'd want to keep parts of your cache only).

This is once per run of kmail-migrator and only if that run is about to 
encounter an unmigrated Disconnected IMAP account.

So it will: 
- at most show once, independent of number of DIMAP accounts
- not show if there is none
- not show if all have been migrated already

> The thing that most users want is probably "keep old data around for some
> time until I know kmail2 works for me". That's essentially "keep old
> data", but with an option to clean up later. Not sure how to implement
> that cleanly (maybe as something that runs when we ship 12.0, though.)

It does do that already.
All cached messages that are not imported successfully, either because they 
are kept explicitly or no imoprt is configured or their import failed (e.g. 
server not reachable during migration), will be accessible as a local maildir 
resource, with a name like "Local Copies of $accountname".

Or maybe easier to understand: all cached mail that is not deleted, ends up in 
a maildir resource which gets configured to work on the DIMAP directory of 
KMail 1.

> > > > However, after migration, i.e. when using the new setup, certain
> > > > portions of the old KMail setup (metadata) might become invalid due
> > > > to folders being modified and thus making the KMail index files "too
> > > > old".
> > > 
> > > Is this reported by KMail then, or what will happen?
> > 
> > AFAIK, KMail will check the timestamp before it attemps loading. If the
> > index  is to old it is ignored and rebuilt.
> 
> Sounds perfectly robust, as no user intervention is needed. Cool :-)

Right.
Some index data cannot be recovered, however. Things like special flags (e.g. 
important), tags and such.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100617/72e90a0e/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/