I've tried to reimport all my kde pim settings after exporting The backup operation said ok zip successfull. I've then clean up my kde environment by deleting all corresponding data & databases. Once relogged in kde I've run the import tools, and get a totally wrong and non corresponding settings. see below Reproducible: Always Steps to Reproduce: 1. Setup akonadi to use an existing external postgresql server 2. setup 16 imap accounts with offline feature all with a nice name like 00_bruno 01_gmail etc to get them organized properly. 3. setup manually correctly the corresponding Trash, Sent, Drafts, Templates folder 4. Let synchronize your offline imap data 312000 files for 8GB in .local/share/akonadi/file_db_data 5. Setup a folder as addressbook 6. Setup a ics file as default Agenda 7. Run pimexporter to get your settings saved 8. Cleanup everything, ask postgresql administrator to drop your database and recreate it clean ALTER DATABASE bf_akonadi SET standard_conforming_strings = 'on'; ALTER DATABASE bf_akonadi SET backslash_quote = 'off'; ALTER DATABASE bf_akonadi SET escape_string_warning = 'on'; GRANT CONNECT, TEMPORARY ON DATABASE bf_akonadi TO public; GRANT ALL ON DATABASE bf_akonadi TO bf_akonadi; 9. Run pimsettingsexporter with import mode, select the .zip, select all + run 10. Start crying and whining :-) Actual Results: An locally personal mysql instance is started and running All accounts failed to connect to the imap, due to missing entries in wallet All accounts get renamed with the ressource filename in place of the nice named given during setup Any folders (trash,sent,drafts,templates) complain that they don't exist and ask to select one, but none of the account work so you have to use cancel. Expected Results: Import run smoothly, without questions, and the restored setup is 100% to what previously exist. A major run in backup is broken, cause nobody want backup, we want restore :-) Now as the tool could be used to migrate settings from one setup to another one at least the configuration of akonadi server should be asked if it's not possible to restore it directly. For special folder in imap mode, another bug entry could be considered : all major imap software are able to link automagically the sended mail folder to Sent if such folder exist on server. (Will improve user experience)
"All accounts failed to connect to the imap, due to missing entries in wallet" we will not store in plain text password no ? I will not do it. "Any folders (trash,sent,drafts,templates) complain that they don't exist and ask to select one, but none of the account work so you have to use cancel." ?
Laurent I mean all accounts failed to retrieve their login information from kwallet (if restored on the previous working computer) I think this is due to the fact that the imap account (name) is not restored correctly example in place of 00_bruno if got akonadi_ressources_0rc name 2nd point : You have to postpond the selection of any special folders ( in restore Trash is asked for each account) until the connection to that account is restored. If there's a failure to connect to that account, there's no other choice than use cancel to continue the next part of the restore.
We don't use same account name id so we can't do it. 2nd point: normal if we don't have connection we don't have folder tree. I can't fix it if you can't connect to it.
(In reply to comment #3) > We don't use same account name id so we can't do it. Okay then the tool can't be used to export & re import the same structure, and thus can't be considered as a backup tool. I would have expected that what is exported/backup is what I will get back. > 2nd point: normal if we don't have connection we don't have folder tree. I > can't fix it if you can't connect to it. Fair enough
(In reply to Laurent Montel from comment #3) > We don't use same account name id so we can't do it. But why we can't use the same account name id? > 2nd point: normal if we don't have connection we don't have folder tree. I > can't fix it if you can't connect to it. This s problem. We can't connect because we use different id in kwallet. We can't get folder tree because we not connected. And we can't set proper folders because we not connected. So, import tool have circular deps.
I ran into the same issue today while trying to restore a configuration on a new laptop. On the original PC I am using pim-data-exporter-19.04.3-2.fc31.x86_64, on the laptop where I want to import I am using 4:17.12.3-0ubuntu1 . Both are the default ones shipped on the respective systems (being Fedora 31 and Ubuntu 18.04LTS). (In reply to Laurent Montel from comment #3) > We don't use same account name id so we can't do it. > How hard would it be to fix this ? I haven't looked at the code (yet). However I think it would be sufficient to export a map of the user-visible account names to account name ids in the backup file and reuse this map to recover e-mail folder names on restore. The data is available on the PC where the backup is created. Why can't it be added to the backup so it can be reused during restore ? > 2nd point: normal if we don't have connection we don't have folder tree. I > can't fix it if you can't connect to it. The issue I see here is not really being unable to connect, but trying to restore folders before actually connecting. When I do a restore I first get a question to choose a trash folder. This trash folder originally pointed at a folder on the imap server. Only after successfully setting a dummy folder the restore process will ask me to connect to the imap server. That's backwards. I would suggest the restore first tries to make all remote connections and only then start mapping folders. Combined with backing up more details of how the accounts were named by the user at the original pc this would tremendously improve the export/import experience. Note I'm also being asked for folders related to 'IDENTITY_12345679' multiple times. The 123456789 changes for each request. I have no idea what these mean exactly.