GNOME Bugzilla – Bug 340766
all notes can be deleted under certain circumstances
Last modified: 2010-12-10 08:30:55 UTC
Please describe the problem: On two occasions, after a system crash I have found all of my notes to be gone. Investigating with strace, it appears that the ~/.gnome2/stickynotes_applet file is written over without using the safe-save method (write to backup, then rename). If this method were used, data loss would be less likely. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information: ubuntu dapper beta
I looked at this. From what I can see, xmlSaveFormatFile does not do an atomic save (writing to a temp file and then renaming). Instead it just writes to the file directly. It is simple to change stickynotes.c to write the XML document to a temporary buffer and then to use g_file_set_contents to do an atomic save. I have a patch to do this, but it is incomplete, as I have not written code to recover from an error (e.g., should it bring up a dialog?) Also I need to figure out how to test it. I'm happy to post what I've got here if that would help anybody.
Created attachment 74312 [details] [review] patch to write atomically This patch changes the sticky notes applet to write atomically, using g_file_set_contents. If the write fails it will pop up a dialog asking the user whether he wants to try again. I'm not super happy with the wording of the dialog (or the buttons). I tested this by making ~/.gnome2 unwriteable, then moving a note (triggering a save). The dialog correctly popped up, and the old file was not removed.
why g_file_set_contents would be atomic ? i think it's not. Why don't you use write a copy and then mv it (just like vim, gedit, etc do) as suggested in the original report ? Because your patch may just fail to write the file over and over and as a result, its content would be incoherent.
I'm just following the documentation for g_file_set_contents, which says that it is atomic. http://developer.gnome.org/doc/API/2.0/glib/glib-File-Utilities.html#g-file-set-contents
"This write is atomic in the sense that it is first written to a temporary file which is then renamed to the final name." great !
It seems like if you answer "no", it's just going to bug you again in 5 minutes, but it seems you've already solved this problem in bug 340769.
Created attachment 74527 [details] [review] updated patch Here's an updated patch that removes the dead code and the schema entry. Yeah, even with a "no" it will keep asking on future saves. And even with the bug #340769 patch, this will be after typing, after moving a window, etc. I'm not really sure what is best. On the one hand this lets you know something is wrong -- and if it something like running out of disk space, or unwriteable directory, etc, you actually could fix it. On the other hand if you can't fix it this dialog will be a constant irritant. I couldn't think of anything reasonable that would fall into the "can't fix it" case though.
We should put this in, so we at least we have atomic saves. We can change the behaviour of the dialog later on if needs be.
I'd be delighted to check this in (plus the other patch) but I haven't had word back from the admins about reactivating my account. So, it may be a while.
Commited this to HEAD. Was it intended for the stable branch as well?
*** Bug 357000 has been marked as a duplicate of this bug. ***
An open issue keeps referring to this bug, which does not seem to be resolved: https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/61570/comments/20 It seems that several people are under the impression that this is an ongoing issue, maybe it should be reopened here, or perhaps its reference removed at bugs.launchpad.net?