rednotebook
rednotebook copied to clipboard
jendrikseipp
add data loss prevention routines
Originally reported by hansbkk at https://bugs.launchpad.net/bugs/907781 (2011-12-22T14:25:00Z):
original posting:
http://answers.launchpad.net/rednotebook/+question/182622
possible suggested solutions:
prompt user on quit before saving -> do allow quit without saving
multiple levels of undo
don't autosave in background (or at least defaults to off)
maybe:
automatically backup one rev (transparent *.bak)
configurable # of backups to a named location
Original comment by jendrikseipp (2012-04-04T19:21:43Z):
A first step has been made: Each day now has its own undo/redo stack. This feature is only available in trunk and hasn't been released yet.
Original comment by hansbkk (2012-04-05T03:12:42Z):
Excellent. So does it work something like this?
Edit 4/5 Edit 5/5
Realize mistake, return to 4/5, undo while focus there, only local changes on that day are undone. Edit some more on 4/5. Go back to 5/5, undo while focus there, only local changes on that day are undone.
If so, most excellent.
Maybe this eliminates the need for allowing quitting without saving changes?
Original comment by jendrikseipp (2012-04-05T09:21:23Z):
Yes, exactly. This definitely needs some testing though when the beta comes out.
Original comment by dolgener (2012-09-17T09:42:36Z):
Just to underline the importance, here is another way you can run into quite massive data loss trouble (at least with v. 1.40):
If your desktop or OS freezes for some other (e.g. hardware) reason and a current writing process is interrupted, the next time you start RedNotebook you'll get:
$ rednotebook INFO Writing log to file "/home/user/.rednotebook/rednotebook.log" INFO MathJax location: http://cdn.mathjax.org/mathjax/latest/MathJax.js INFO Running in portable mode: False INFO First Start: False INFO RedNotebook version: 1.4.0 INFO System info: machine: i686, platform: Linux-3.0.0-1-686-pae-i686-with-debian-wheezy-sid, processor: , python_version: 2.7.3rc2, release: 3.0.0-1-686-pae, system: Linux, GTK version: (2, 24, 10), PyGTK version: (2, 24, 0), Yaml version: 3.10 INFO Cloud ignore list: [u'category', u'diese', u'einem', u'einen', u'einer', u'entries', u'entry', u'filtere', u'gegen', u'getrennten', u'hatte', u'kommas', u'mit', u'nicht', u'wolke', u'w\xf6rter'] INFO Cloud include list: [u'job', u'juli', u'mtv', u'spam'] INFO Using zeitgeist: False INFO Opening journal at u'/home/user/.rednotebook/data' ERROR Error in file /home/user/.rednotebook/data/2012-09.txt: while scanning a quoted scalar in "/home/user/.rednotebook/data/2012-09.txt", line 85, column 11 found unexpected end of stream in "/home/user/.rednotebook/data/2012-09.txt", line 100, column 1
This affects any portion from the smallest unit being saved, in this case up to a month.
IMHO this damage could easily be prevented by saving the file in a transactional manner (delete old backup ; move old file to new backup ; then save new file) as e.g. kate/kwrite an other editors do. In that case, only few information would be lost that had been changed during the last auto save interval.
Of course downsizing the smallest unit of information (month -> day, as maybe V. 1.5. does) and maybe saving a undoable/redoable history in addition would greatly help, too. The latter theoretically might enable a complete recovery up to few keystrokes.
Hence, I'm looking forward to v. 1.5 (it has not yet arrived at debian/experimental).
Original comment by jendrikseipp (2012-09-19T17:43:54Z):
@dolgener: Thanks for your idea! I will implement transactional saving when time allows.
Original comment by paytonturnage-deactivatedaccount (2012-12-13T14:27:49Z):
What about a backup cycle? In Adobe After effects the autosave feature alternates around 5 incremental backups. In this it would mean having (maybe in the program's directory) 1.bak after a givent interval of time, then 2.bak, up to 5 where it would overwrite the 1.bak (the number of stages could be adjustable).
Original comment by jendrikseipp (2015-01-03T19:46:40Z):
I found the time to implement transactional saving as dolgener suggested. The new file is written to a temporary location and only if writing succeeds, we move it to the regular location. The feature will be included in version 1.10.
Original comment by dolgener (2015-05-12T09:20:49Z):
Seems to reduce the data loss risk. However, if you work on multiple activities (KDE) or Desktops and unintendedly get rednotbook runnig twice, editing the same day (likely today), you're about to lose data.
Besides that, it's just nasty ,-)
Maybe from tendo import singleton me = singleton.SingleInstance() # will sys.exit(-1) if other instance is running) is a suitable solution? (See http://stackoverflow.com/questions/380870/python-single-instance-of-program, first answer)
Even with the transactional saving data loss is possible if the application writes garbage (as is apparently sometimes the case: https://answers.launchpad.net/rednotebook/+question/675433). RedNotebook should therefore try to read the written output and only if it's fine delete the backup copy. The singleton proposal is still another good idea.
The solution I mentioned in my previous message has been implemented in a recent version.