Summary: | pimsettingexporter does not restore data it exported | ||
---|---|---|---|
Product: | [Applications] pimsettingexporter | Reporter: | Bill <bill> |
Component: | general | Assignee: | Laurent Montel <montel> |
Status: | REPORTED --- | ||
Severity: | critical | CC: | audun, bmikowski, cfeck, kdebugs, pieterkristensen |
Priority: | NOR | ||
Version: | 4.10.5 | ||
Target Milestone: | --- | ||
Platform: | Mint (Ubuntu based) | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
kmail after restore backup
attachment-25026-0.html |
Description
Bill
2013-10-06 22:35:39 UTC
Firstly 4.10.x is too old for this application use 4.11.x Secondary when I use kmail I will not read my email with konqueror so you export with pimsettingexport you import with pimsettingexporter... "what format it would be exported under" you need it ?? you know where you store data no ? "I extracted the exported data, and found all of the settings and info are still there- I simply cannot restore it" normal and you can not do it with real data stored in .kde/share/config/* Now what is not restored ? What bugs etc ? And not I use this program to export and use this other program to import and I can't import... >Firstly 4.10.x is too old for this application use 4.11.x If 4.10.x is no longer supported, please remove it as a selection from your bug reporting tool then. Never mind that it is released under the most current version of Linux Mint. >Secondary when I use kmail I will not read my email with konqueror so you export with pimsettingexport you import with pimsettingexporter... I have no idea what you mean here. Are you saying I'm trying to read my email via KDE's web browser? That was never mentioned in my report. If you re-read what I posted, I made it clear I am trying to import with pimsettingexporter what was exported with pimsettingexporter. You can deny that there is an issue or not, but people have been trying to figure this out since 2007. >"what format it would be exported under" you need it ?? Yes, I do need it documented. So do other people. You are presuming that everyone who uses your application is a KDE dev who has worked on your application or is intimately familiar with the unpublished specifications of the KDE user directories. I am telling you that the average user is going to have no idea how to fix their issue if you don't document your work. Is there even an export manifest somewhere in the file? Are the commands to pull and restore to the Akonadi DB documented? No? How will the average person know what to do then, when things go wrong? How will distribution maintainers know what to avoid doing? >you know where you store data no ? Actually, no, I don't. Please point me to the formal KDE documentation that delineates where this data should go, and how it should be restored, including the Akonadi DB commands. There is no such documentation. For the average user, this is a serious issue in usability. For a systems administrator, this is a lot of wasted time trying to backtrack someone else's work. >"I extracted the exported data, and found all of the settings and info are still there- I simply cannot restore it" normal and you can not do it with real data stored in .kde/share/config/* When I try to restore, it restores NO DATA. At all. Even in places it may think it should be default- which is another issue, because those defaults aren't documented either. If you are saying that I should have manually backed up all of my files instead, then that appears your tool cannot be trusted with this data- and one of my suggestions is that it be disabled in the KMail menu until the issues with it are worked out- that way users would be encouraged to NOT use a broken tool. >Now what is not restored ? Nothing is restored. Period. That is the point of having a feature that can back up and restore. Having documentation of the "right way to do it" means downstream providers like SuSE and Linux Mint will have a roadmap for file and directory naming conventions, so they can be consistent in building your app. Again, I have no idea where this data should be restored to- there is no documentation provided, and a directory manifest does not appear to be created by the app, as far as I can tell with a cursory overview of the backed up data. Moreover, there is the issue of restoring to the Akonadi DB. Again, I am not a regular user- because a regular user never would have gotten this far. A regular user would have given up, and either lived with all of their lost data and moved to Thunderbird, or would have cursed the day they thought Linux was a good idea, and bought a copy of Windows or OSX. >What bugs etc ? They were just reported. Obviously, you do not see this as an issue- but then that is the exact purpose of a bug report, to report issues that devs do not see, yes? If you are saying this is a downstream provider issue, then why has this been an issue since 2007, with multiple distributions? Go look around on the web, and see what people are saying about using this tool. Did you think I didn't spend some time trying to figure out whether someone else had the same problem before I submitted this? I'm not the only one with this problem, just one of the few to report it. Considering the track record I've had in submitting bugs to KDE, I'm likely not going to put much more effort into this. You seem to be more incredulous and bothered than interested. The last bug I reported was for calendar data disappearing- it was closed twice by the dev, reopened by other affected users who were castigated by the dev in charge of fixing it, and then fixed THREE YEARS LATER by someone else on the core KDE dev team who finally ran into the problem. Since your response has been 1) blame the downstream provider; 2) say it must be old code, upgrade to code you can't upgrade to; 3) claim user incompetence/ignorance; and 4) ignore the report; I'd say that I'm on track for this being fixed in, what, 2016? This is the last bug I'm going to file with KDE. I'm done. I really like most of the features of KDE, Kontact is an amazing product when it works, but the attitude of the devs is worse than anything I've experienced from any other project. So, close the bug, do what you like- you clearly are going to anyways. On Sun, Oct 6, 2013 at 10:59 PM, Laurent Montel <montel@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=325727 > > --- Comment #1 from Laurent Montel <montel@kde.org> --- > Firstly 4.10.x is too old for this application use 4.11.x > > Secondary when I use kmail I will not read my email with konqueror so you > export with pimsettingexport you import with pimsettingexporter... > > "what format it would be exported under" you need it ?? you know where you > store data no ? > "I extracted the exported data, and found all of the settings and info are > still there- I simply cannot restore it" normal and you can not do it with > real > data stored in .kde/share/config/* > > > Now what is not restored ? What bugs etc ? > And not I use this program to export and use this other program to import > and I > can't import... > > -- > You are receiving this mail because: > You reported the bug. > Bill, the attachment is missing. If you cannot attach it, because of size or confident data, you can also mail developers directly (after prior consultation). Also, please also do not use terms such as "Follow directions" when describing steps you made; developers can only reproduce when there are detailed descriptions. I found this bug when trying to determine if it was safe to restore a prior backup I made. To make a long story short, I backed up two email accounts when having Kontact/KMail stability issues. A webmail client was used on one account for two weeks until the Akonadi backend stabilized (e.g., losing downloaded emails, akonadi DB corruption messages, etc). I backed up two email accounts 3 times over several weeks, patching KDE apps from my distro until Akonadi stabilized. The export/backup files are saved in .zip format on export. I examined the contents of the zip files over that time period and noticed that the first backup contained 1.9GB of mail, whereas the *newer* backup files contained practically zero mail content on export. (e.g., \mails\akonadi_maildir_resource_3\local-mail file was 1.9GB in the 9/14 zip file, and is now only 6.8KB in the 9/15 and 10/8 files) I also until now never had succes with the backup/restore of kmail. When I backup my six accounts with six identities I completely follow what the wizzard tells me to do. Then, when I restore on another machine the program asks me for the location of many folders (I wouldn't be supprised if I'm asked thirty times ore more). This annoys me. When this is over and kmail is started there is no workable situation. The layout of the program and the identities are correct but the accounts have different names and absolutely won't work. There is no way to find out for me if the date are wrongly EXported or IMported. The result just is nog good. At least the layout of kmail is correct. I'm sorry I forgot to mention that I am using Kubuntu Saucy Salamander 32 bit. With KDE 4.11.2. I had to install the mysql-client before getting the pim-exporter to work at all. This dependency was missing. Perhaps there is missing another dependency? I fixed import accounts in 4.11.3 Needs to look at import mails there is a bug somewhere. I fixed import/export mails/notes/calendar/alarm/addressbook in 4.12* I thank you for the great work and you openness. I can't wait to use the software! I'm very sad to say that kde 4.11.3 under Kubuntu didn't at all change things for the good. I made a backup of my kmail data, then I created a new user (sudo adduser) I logged out and after that I logged in as the new user and I "restored" the kmail data. It still doesn't work. Accounts are wrong, (strange names, strange content) in the "identeties" are omissions and I'm asked over and over for folders. The result still is not workable. I deleted the user with the graphical user management and tried again. Again it didn't work. I have six imap accounts and one pop3 account set up in kmail. I never wrote that it was in 4.11.3 I put some fix in 4.11.4 and all other fix are in 4.12 I fixed account name (in 4.12) I fixed synchronize account after import it (4.12) I improve synchronize in 4.13 (big changes). Now it doesn't freeze UI when we sync it. I continue to fix it. I fixed an other bug when import zip file (in 4.12) Great! Kmail will be a very good appication! KJots import/export fixed now Knotes export/import fixed I'm on Kubuntu Trusty 64 bit now. It uses KDE 4.12.97. As far as I can see import/export of kpim works now BUT I regret to say that I still cannot import my kmail data properly. Still the accounts get the weirdest names when imported and still the system keeps asking for folders during the import proces. (In reply to PK from comment #17) > I'm on Kubuntu Trusty 64 bit now. It uses KDE 4.12.97. > As far as I can see import/export of kpim works now BUT I regret to say that > I still cannot import my kmail data properly. > Still the accounts get the weirdest names when imported and still the system > keeps asking for folders during the import proces. I can confirm it on KDE 4.14.3. I'm using Gentoo Linux amd64. > and still the system keeps asking for folders during the import proces It's annoying me. Maybe this bugs fixed in trunk? I can test import and export again and again, if it help you. Just say me what additional info I should provide. Created attachment 92216 [details]
kmail after restore backup
How Kmail looks like after restore backup. And what the "AbCeCaC0CbDcCdE6 D2C5CaC8"?
@Andrey what was the original name ? I don't generate random name so perhaps it was russian name and when I save or load it I don't get correct name. Git commit 6e841fe7bdd456e40504aeba03af969ce43894c8 by Montel Laurent. Committed on 26/04/2015 at 06:26. Pushed by mlaurent into branch 'KDE/4.14'. Fix load agent name. M +2 -2 pimsettingexporter/abstractimportexportjob.cpp M +1 -2 pimsettingexporter/addressbook/importaddressbookjob.cpp M +1 -2 pimsettingexporter/alarm/importalarmjob.cpp M +1 -2 pimsettingexporter/calendar/importcalendarjob.cpp M +1 -2 pimsettingexporter/jot/importjotjob.cpp M +1 -2 pimsettingexporter/mail/importmailjob.cpp M +1 -2 pimsettingexporter/notes/importnotesjob.cpp M +5 -3 pimsettingexporter/utils.cpp M +1 -1 pimsettingexporter/utils.h http://commits.kde.org/kdepim/6e841fe7bdd456e40504aeba03af969ce43894c8 Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. Created attachment 136556 [details] attachment-25026-0.html As noted in my comment from 2013, the report can be closed. I can't confirm whether the bug is fixed, because I did what I said in my response to the dev who said it wasn't an issue- I stopped using KDE, and haven't used it since. On March 9, 2021 5:36:09 PM EST, Justin Zobel <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=325727 > >--- Comment #22 from Justin Zobel <justin.zobel@gmail.com> --- >Thank you for the bug report. > >As this report hasn't seen any changes in 5 years or more, we ask if >you can >please confirm that the issue still persists. > >If this bug is no longer persisting or relevant please change the >status to >resolved. > >-- >You are receiving this mail because: >You reported the bug. ___ Bill Albertson bill@blowfish-labs.com $ pimdataexporter -v QSocketNotifier: Can only be used with threads started with QThread pimdataexporter 5.20.0 (22.04.0) I tried it recently this March, and the restore is a complete mess. SMTP servers appear several times, but with port set to 1 and missing most of the settings. A lot of mail is just lost. Restore is around 3.5G out of 12G, and it restores to .local/share/0/local-mail instead of .local/share/local-mail. Identities are without name and settings are lost. This is really not something that should be used until it works. |