Re: kmail and the folders

On Saturday 31 December 2011, Martin (KDE) wrote:
> Am 31.12.2011 18:48, schrieb Ingo Klöcker:
> > On Saturday 31 December 2011, Martin (KDE) wrote:
> >> Am Samstag, 31. Dezember 2011, 18:08:56 schrieb Martin:
> >>> Hallo
> >>> 
> >>> I recently moved from one 32 bit system to my new 64 bit system.
> >>> As I use a centralised home system Installation was not that
> >>> complicated, but kmail made a mess out of my folder
> >>> configuration (all in one single online imap server).
> >>> 
> >>> So I took the chance and a look into kmail2rc file. There are
> >>> many folder based configurations like:
> >>> 
> >>> [Folder-22]
> >>> ExpireAction=Delete
> >>> ExpireMessages=false
> >>> ExpireToFolder=
> >>> HideInSelectionDialog=false
> >>> IgnoreNewMail=false
> >>> MailingListArchiveAddress=
> >>> MailingListEnabled=false
> >>> MailingListFeatures=0
> >>> MailingListHandler=0
> >>> MailingListHelpAddress=
> >>> MailingListId=
> >>> MailingListOwnerAddress=
> >>> MailingListPostingAddress=
> >>> MailingListSubscribeAddress=
> >>> MailingListUnsubscribeAddress=
> >>> PutRepliesInSameFolder=false
> >>> ReadExpireAge=3
> >>> ReadExpireUnits=3
> >>> UnreadExpireAge=12
> >>> UnreadExpireUnits=0
> >>> UseDefaultIdentity=true
> >>> htmlLoadExternalOverride=false
> >>> htmlMailOverride=false
> >>> 
> >>> But what is missing: which folder does this configuration belong
> >>> to? Wher do I get the folder name from this configuration belongs
> >>> to?
> >>> 
> >>> Anyway, now the configuration for my previous digikam-user
> >>> mailinglist folder (was Folder-99) now belongs to my kde
> >>> announcement folder.
> >>> 
> >>> Last time I had such a mess I lost mails due to wrongly assign a
> >>> mailing list folder with expiration set to my sent folder.
> >>> 
> >>> Isn't this a little bit risky to assign completely unrelated
> >>> configuration to folders they don't belong to? I have to check if
> >>> there are mails missing in all my sub folders.
> > 
> > Yes. This has already been discussed in a recent thread.
> > Apparently, the numbers of the folders correspond to UIDs of those
> > folders in Akonadi. The problem here is that those UIDs are only
> > unique as long as the Akonadi database exists.
> > 
> > Two solutions were discussed in this thread:
> > - Move folder specific settings to Akonadi. This way they can never
> > be used for a wrong folder.
> > - Use some kind of UUID for identifying the folders.
> 
> So no need of reporting a bug?

I'm not sure whether a bug was reported for this, but it also concerned 
expiration settings being applied to wrong folders.


> >> So, setting delete on expiration is definitely a bad idea if you
> >> plan to move your mail base around. I lost many mails (thanks to
> >> backup not permanently). I don't know why this happened, why
> >> kmail set expiration to the wrong folders. I have to file a bug
> >> on this issue then.
> > 
> > I guess you've deleted Akonadi's database which caused the loss of
> > the folders' UIDs. Unfortunately, KMail did not take care of
> > removing the now invalid folder settings. Did you re-add the mail
> > accounts from within KMail? Or did you re-add corresponding
> > Akonadi resources without KMail's help?
> 
> Hm, I did none of them. I sync my home folder except of the akonadi
> DB from the server (takes to long to sync). As this is a new
> computer there was no akonadi DB, but the akonadi configuration was
> synced.
> 
> So, as I think about it, I "deleted" the akonadi DB.
> 
> This lead me to another question: shall I sync my akonadi DB as well?

Yes. Currently, the necessary information is stored partially in the 
Akonadi database and partially in config files. If those two get out-of-
sync all kinds of problems may occur. (This situation is not ideal, but 
that's how it is.)


Regards,
Ingo

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEABECAAYFAk7/elAACgkQGnR+RTDgudj2dQCeLOOQouEzXgNKyv7cIdyB5Kv5
VmcAn3Pm1eWCiWsYBdkyy1pOTu2sImpF
=XGVH
-----END PGP SIGNATURE-----