Notes not saved on quit in newer versions #318
Comments
|
This is not much of a test as it is a secondary OS with few notes, but I tested a short note on Artix (which started its life as the OpenRC version of Manjaro back in the day) with 0.40 and had no problems with the save running either E or XFCE. How large are the notes you are saving and how many notes? Desktop Environment? Those things might help Davo track this down. |
|
Yeah, this is a nasty problem indeed. Anything you can provide to help me replicate it will be very, very gratefully received. I tested on my system by opening a new note, pasting in 100K of text and immediately closing -ng. One reopening, it was all there. I tested by (immediately) closing the note and (immediately) closing the application. All good in both cases. I take it by 'quit' you don't mean closing the whole computer down ? (That should be OK too but not absolutely certain, all systems will give an app only so long to do what it needs to do.) As aguador suggests, maybe the desktop is more important here than the distro, what is your desktop please ? And version of Manjaro ? I might need to build a replica .... Also be nice to know where you are saving your notes, its not to a shared or on-line drive perhaps ? Wild guess, you are not using some particularly slow drive ? And encrypted drive ? Nothing worth mentioning has changed in the file saving model for quite some time so, there is, IMHO, a risk of this problem showing up even in the older version of tomboy-ng. We need to get to the bottom of it ! Davo |
|
Hi, thanks for the follow up. Yes, when I say quit, I mean quitting the program (ctrl-Q). I have 287 notes. Most of them are not very long, but a few are. (I have noticed that for a while that with long notes, typing starts to get slow.) I'm using the Mate desktop. My hard drive is encrypted (but it's an SSD, so it's not slow and I have no issues with other programs). The notes are saved locally, in my /home partition. I'm not sure what you mean by what version of Manjaro, since it's rolling release. This is a system I set up a long time ago (not long after Manjaro first came into existence) and I've just been rolling ever since--which remarkably few problems. The hardware is pretty old (it's an old ThinkPad). One thing I notice is that if I make a change to a note an * appears next to the note name, in the title bar of the window for the note, to indicate a change has been made. After about ten seconds the note saves and the * goes away. This is the same in 0.36b, as well as in the newer versions. But in the newer versions, if I don't wait until that autosave happens, and quit while the * is still thre then the note is not saved on quit. Whereas in 0.36b, as I described, if I quit immediately, while the * still shows that the note has not been autosaved, the note still saves on quit, as expected. Any thoughts? Any more information that would be useful? |
|
OK, you have answered very well but I am not sure I can see any hints about what is happening. I will build a Manjaro, if its rolling, I will should up same condition as you. I too use Mate. Yes, that * indicates content is unsaved. Its done on a timer, while someone is typing, they don't want file i/o happening. As you said, it all slows down as a note gets "too long", its dependent on hardware and he degree of markup in the note. But for its purpose, "notes" rather than "manuscripts" its usually OK. I test on an old, Atom powered E-Machine ! When you close the app down, it should keep itself open until after it has finished all the saving necessary. How that is not working for you, I really don't know. But we need to find out ! I will build my version of your system, see if I can replicate the problem. If I don't, it may come down to me sending you a special version that logs the process, that will be revealing ! I will get back to you ! EDIT: first problem, no Manjaro with Mate by default. I'll pull down an XFCe one and, post install, update it to Mate. Sigh, horrible package manager .... Davo |
|
Thanks for pursuing this problem. That's disappointing that there's no Mate Edition of Manjaro anymore. It looks like they dropped it just a few months ago. One of the reasons I originally came to Manjaro was because it was an early supporter of Mate. |
|
NOTE: please don't do this test with a note thats of any value, there is every chance it will corrupted ! It was quite easy to add Mate to an XFCe Manjaro, in fact it looked quite good. But I could not live without apt ! But no progress here. My mock up of your system works perfectly. Sigh ... So, here is a test binary that will drop, to the console, some data about whats happening as you quit -ng. I suggest you unzip this file, it contains one binary called "tomboy-ng", do not install it, just drop it somewhere convenient and run it from the command line. Make sure your existing one is stopped first, else it will take over. Do your trick please, open a new note, paste in a heap of content and click quit immediately. The process should leave 8 lines of text, each showing the method it was called from, the time (to the millisecond) and, in some cases, the note title. If you could copy and paste those line here, I may become a bit wiser ! |
|
I ran the test version of tomboy-ng twice. The first time I created a new note, saved a bunch of text, and immediately quit. But it saved the note. Then I ran the test version again and made a slight edit to the new note, quit immediately, and the edits were not saved. Here's the output from the terminal. Because I have several notes I leave open, that open when I launch tomboy-ng, I edited the output just to change the name of those existing notes (so the output says instead note1, note2, etc.). But the new note I created can be seen as: "New Note 2024-10-15 00:01:38.032." Run 1:
Run 2:
By the way, the problem with edits to notes not being saved on quit is not related specifically to notes that have a very large amount of content. It was a fairly short note that I first noticed the problem with. Also, I don't know if this matters, but as I said, I do tend to leave a few note windows open when I quit that reopen on launch. Including one that is a fairly long note. Maybe that is part of the necessary conditions to trigger this problem? Curiously, while I was quitting and restarting to run this test, that long note got corrupted and I had to recover it from the backup folder. |
Woops, thats something I missed ! I have deliberately but unintentionally been avoiding what (probably) I needed to look at. I rarely shut -ng down in normal use and, when developing, I carefully close down most if not all notes before closing the app. I'll look through your data and see if it points to my new theory but might need to send you another test case. But I suspect I might be able to replicate the problem with the "lots of notes trick" ! Thanks, your help here is appreciated ! Will get back to you. Davo EDIT : yep, I can duplicate the problem, right here on my laptop ! |
|
I'm glad you were able to duplicate the problem! Hopefully that will help resolve it. Some further notes. I don't really have a lot of notes left open, just five. But I suspected the problem might be the one long note (1300 words) that I left open, since that was the note that got corrupted when I was running your test binary. So I tried it again and indeed that was causing the problem. If I close the one long note and leave the other four notes open, then an edit to one of the shorter notes saves on immediate quit. But if I have five notes open, including the longer note, then the edit does not save on quit. Experimenting further, if I have only the long note open, or the long note and one other note, edits save on quit. But once I had three notes open, including the long note, then edits did not save on immediate quit. So guess perhaps it's just some total amount of text between the notes and over that threshold, the failure to save on quit occurs? |
|
I think it relates more to the number of notes being saved rather than the size. I have had a bit of time to dig into it and believe that due to a couple of separate issues, each introduced in to code at different times. When a note save is delayed because another note is already being saved its setup to keep trying, but if a third one joins the queue, they can fight over who gets to go first and block any remainder. I do like to save sequentially to play safe. Its slower but thats only a factor when Quitting IMHO. I have been testing my fix, have a 100 notes open at once now and all are saved with no errors ! Fun Fact, its dead easy to open 100 notes all at once. Quit and they will all return, every time ! Its quite tedious closing, one by one, all of those notes by hand ! I will do some more cross platform testing, want to see how it works on my little Atom machine and the Raspberry Pis ! But as I have made quite a few changes to the save system, and its critical, I need to test extensively before anyone else sees it. When I am a bit happier, I'll let you have a sneak preview ! Davo |
|
Sounds great. Thanks for your work on this. |
|
OK, attached (if its not too big) is a new pacman package, gtk2, 64 bit, think thats what you are using ? I will probably push this out as a full release before long given this problem you experienced could hit anyone. Its really quite nasty. Please install this package, if you do see any problem, please let me know, remove it quickly and get back to your 0.39 ! As well as your problem, it does fix some more obscure problems you are unlikely to notice (unless you create PDF's in Chinese ?). Multiselect notes in the search window and its right click menu is new .... Thanks for your help and understanding here, this was, as I said, a nasty problem ! Davo Ah, damm, github insists I zip it, so, please unzip then do the usual pacman thing .... |
davidbannon
added
Wait on User Response
fixed in next release
|
Hi, sorry I dropped the ball on this for a bit. I had to go out of town to deal with some family things. Anyway, I installed the latest package and it seems to be fine. Opened a bunch of notes, made some edits, immediately quit, and the edits were saved each time. I wouldn't say I exstensively tested it. But the same conditions that triggered the problem before, which were easy to reproduce, do not now. |
|
Thanks, I cannot break it either. I think I had better rush out a new release, its quite a serious bug ! |
I was running an older version of tomboy-ng, 0.36b, without problems, on Manjaro. Then I realized I'd missed many updates and upgraded to 0.40, gtk2 version.
In version 0.40, if I edit a note and quit right away, the edits are not saved and I get four notifications saying, "Failed to auto save" (I would sometimes get a single notification saying this with 0.36b, but notes always saved nonetheless). In 0.40 I have to wait about ten seconds, for the edits to save, before I quit, although I still get the four "failed to autosave" notifications.
I tried versions 0.39 and 0.37, as well as the qt version of 0.40, but they all had the same problem.
So I reverted to 0.36b and notes save on quit, as expected.
The text was updated successfully, but these errors were encountered: