Summary: | when creates a new note knotes create two and then a warning appear and the note is not saved | ||
---|---|---|---|
Product: | [Unmaintained] knotes | Reporter: | pier andre <pier_andreit> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | mcpain, myriam, rafael.linux.user, wbauer1 |
Priority: | NOR | ||
Version: | 4.13 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/knotes/7f92d12de349e54fd7c505d014015db5ea80b9e8 | Version Fixed In: | 5.9.0 |
Sentry Crash Report: |
Description
pier andre
2014-04-30 15:02:01 UTC
following trials.... https://forums.opensuse.org/showthread.php/497628-kde-4-13-0-in-opensuse-13-1-knotes-doesn-t-create-a-new-note-and-in-12-3-yes?p=2640480#post2640480 as in the main user this worked rename the folders ~/.config/akonadi and ~/.local/share/akonadi when akonadi is stopped. ....I login the new user I create to make the same thing I did in the main one, launched akonaditray to stop akonadi and....., akonadi was not running...., this probably was the why knotes double the notes..., started akonadi and now knotes works perfectlydoesn't double the notes but doesnt save it, I suppose akonaditray popup this notification: notes cannot write to mail file /home/user/.local/share/akonadi_aconotes_resource_0/tmp/a-long-number-and-the-host-name and this folder doesn't exist, if I create a new agent in akonaditray and assign it to the default in knote config knote works well (In reply to comment #1) > but doesnt > save it, I suppose akonaditray popup this notification: > notes cannot write to mail file > /home/user/.local/share/akonadi_aconotes_resource_0/tmp/a-long-number-and- > the-host-name > and this folder doesn't exist, if I create a new agent in akonaditray and > assign it to the default in knote config knote works well I got the same error messages here after the successful migration (with a different folder though, something in ~/local/share/notes/). Everything worked fine, so I didn't bother until now. But now I noticed that the notes don't get saved to the hard disk at all (they only exist in the akonadi database), because that folder that the akonotes resource points to didn't exist (and didn't get created either). I tried to reproduce the problem by redoing the migration a few times, and I found out this: - If I start knotes from a Konsole, the folder for the new resource is created, and everything works fine without any error messages - But: if I start knotes from the K-Menu (the first time, when it should do the migration), the folder DOES NOT get created. Akonadi fails to store the notes, and akonaditray gives those annoying error messages. This seems to be reliably reproducable here, I tried about 10 times now or more. So I guess the question is, what's the difference if knotes is started in Konsole vs. it is started by K-Menu? Why does it fail to create the folder in the second case? Oh, and btw, I started knotes without akonadi running now by mistake, then the migration FAILED (the migrator showed some message about "Could not find root collection"). Some kind of timeout maybe because akonadi needed too long to start? This is also reproduceable, I will file a new bug about this. (In reply to comment #2) > I tried to reproduce the problem by redoing the migration a few times, and I > found out this: > - If I start knotes from a Konsole, the folder for the new resource is > created, and everything works fine without any error messages > - But: if I start knotes from the K-Menu (the first time, when it should do > the migration), the folder DOES NOT get created. Akonadi fails to store the > notes, and akonaditray gives those annoying error messages. > > This seems to be reliably reproducable here, I tried about 10 times now or > more. > Hm, suddenly this also happens quite reliably when starting knotes from Konsole, so the way it is started doesn't really seem to be the trigger. Some general race condition? I have had the same problem (duplicate note on creating new note) only one time. My notes are saving and no more times for this problem. (In reply to Rafael from comment #4) > I have had the same problem (duplicate note on creating new note) only one > time. My notes are saving and no more times for this problem. I encountered the same problem right now, and found out what's causing it: this happens when you create a new note and the default collection is not enabled. You are asked whether the collection should be enabled, and if you click "Yes", _two_ new notes windows are opened. But they show the same (new) note really, that's why you get the conflicts. If you click "No" in that dialog, no window is opened as expected. But if you click "Yes" the next time, you even get _three_ windows. And if you manually enable the collection _without_ creating a new note, suddenly all those notes you created (where you selected "No" in the dialog) pop up as well. So apparently the creation of the note is not really aborted in that case. Not sure if it should be, but as no window appears, this is definitely confusing to the user. knotes 18.04.2 When I try to create a note in hidden collection the note is created and fetched from Akonadi collection simultaneously, leading to appearing the same note twice. https://phabricator.kde.org/D14208 Git commit 7f92d12de349e54fd7c505d014015db5ea80b9e8 by Laurent Montel. Committed on 19/07/2018 at 11:25. Pushed by mlaurent into branch 'Applications/18.08'. Apply patch from Oleg Solovyov Fix Duplicated notes in KNotes Test plan: Hide collection Create a note and put it to hidden collection Your note will appear once (twice w/o fix) FIXED-IN: 5.8.0 Differential Revision: https://phabricator.kde.org/D14208 M +1 -1 src/apps/knotesapp.cpp https://commits.kde.org/knotes/7f92d12de349e54fd7c505d014015db5ea80b9e8 |