add data loss prevention routines

Bug #907781 reported by HansBKK
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
RedNotebook
Confirmed
Medium
Jendrik Seipp

Bug Description

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

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

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.

Changed in rednotebook:
assignee: nobody → Jendrik Seipp (jendrikseipp)
security vulnerability: yes → no
visibility: private → public
Changed in rednotebook:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
HansBKK (hansbkk) wrote :

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?

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote : Re: [Bug 907781] Re: add data loss prevention routines

Yes, exactly. This definitely needs some testing though when the beta
comes out.

Revision history for this message
Dolgener (dolgener) wrote :

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).

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

@dolgener: Thanks for your idea! I will implement transactional saving when time allows.

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

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.

Revision history for this message
Dolgener (dolgener) wrote :

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)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.