m0j0hn / editor-on-fire

Automatically exported from code.google.com/p/editor-on-fire
Other
0 stars 0 forks source link

Crash recovery #247

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
As requested here:
http://www.fretsonfire.net/forums/viewtopic.php?f=11&t=50698&p=583115#p583112

Since EOF 1.8 is not that stable yet, having the ability to recover the chart 
that was open could be a useful feature.  EOF saves undo states that could 
easily serve this purpose, but to make this feasible, the full path to the 
last-opened chart would need to be saved in a recovery file each time an 
undo/redo state is made, so that if the user does recover from a crash, the 
correct audio could be loaded with the file.

Original issue reported on code.google.com by raynebc on 25 Mar 2011 at 3:28

GoogleCodeExporter commented 8 years ago
EOF's current undo system probably makes this unnecessary.  If the program 
crashed, the last-modified .undo file could just be loaded.  It's not 
automatic, but making it automated would be a huge amount of work.

Original comment by raynebc on 17 Oct 2011 at 11:50

GoogleCodeExporter commented 8 years ago
Being able to have multiple EOFs running at once complicates this, although 
doing so is probably not going to be the most common use.  This could be 
implemented as one or more files.  If an eof.recover.on file does not exist in 
EOF's program folder during launch, it will be assumed that no other EOF 
process is performing this function and the file will be created and LEFT OPEN 
to prevent a second instance from doing it.  When an undo state is made, an 
eof.recover file can be opened and the full file path to that undo state can be 
written to file.  During normal program exit, the eof.recover and 
eof.recover.on files can be deleted.

During launch, if the eof.recover.on file is found, the EOF instance can test 
to see if there was a crash condition by attempting to delete the file.  If it 
still exists after a deletion attempt, it's because another EOF instance is 
running with that lock file still open.  Otherwise it can be assumed that the 
file remains due to a crash from a previous instance.  If eof.recover exists 
and contains a path to a file that exists, EOF can offer to reload that undo 
state.  If the user opts to do so, the undo state is loaded.  After the auto 
recovery prompt is answered, the recovery files can be deleted so that this EOF 
instance.

Original comment by raynebc on 18 May 2012 at 7:10

GoogleCodeExporter commented 8 years ago
..can maintain the path to the last undo state.

Original comment by raynebc on 18 May 2012 at 7:13

GoogleCodeExporter commented 8 years ago

Original comment by raynebc on 18 May 2012 at 11:35

GoogleCodeExporter commented 8 years ago
Completed in r902.

Original comment by raynebc on 22 May 2012 at 9:18