Don't ever overwrite or delete recover files #2174

Closed
unfa opened this Issue Jul 9, 2015 · 7 comments

Projects

None yet

5 participants

@unfa
Contributor
unfa commented Jul 9, 2015

I just lost some serious progress because I closed LMMS after recovering from a crash and forgot to save the project. LMMS deleted the recover.mmpz file and my progress is lost forver. It'd be great if it didn't do that, and name the recover files with Process ID and date like this:

recover_PID7632_2015-07-09-1348.mmpz

It'd make all recover files be there if needed. They are not very big, could be automatically removed after a month or something. That'd greatly increase the crash recovery probability and make it resistant to running multiple LMMS instances that overwrite recorver.mmpz causing data loss.

@zonkmachine
Member

Ouch! Sorry about your data loss. Been there...

The line removing the recovery file is here:
https://github.com/LMMS/lmms/blob/master/src/gui/MainWindow.cpp#L1259

How does other programs do it?
I can recall seeing recovery files popping up in other programs and they would make some "noise" like adding a red border saying recovery file. I think a good way to deal with this would be to just add the usual question on closing. If I modify a new project and press 'close' I get "The current project was modified since last saving. Do you want to save it now?"
Maybe something like: "You are about to close a recovered file but it is currently in an unsaved state and will be lost if you don't save it. Do you want to save it now?"

@unfa
Contributor
unfa commented Jul 9, 2015

Thanks, I managed to redo it more or less. Anyway, I'd like to expand the autosave funcionality a bit.

@zonkmachine
Member

OK. I'm going to look into how recover files are handled.

@zonkmachine
Member

Post edited!

Method to reproduce goes something like:

  • In master, put a project file "recover.mmp" in the working directory ~/lmms
  • Start LMMS
  • Close LMMS
    The recover.mmp file is gone, no questions asked. This is definitely a bit on the brutal side.
@zonkmachine
Member

I'm going to hack this a bit to give us a question box on closing a recovery file.

@musikBear

so sad @unfa - if you had seen what i suggested the other day
#181
you would have liked it
I reference to 181 because i think it has very strong relation to this thread, and the handling of recover in a whole

@tresf
Member
tresf commented Jan 19, 2016

Closed via #2176

@tresf tresf closed this Jan 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment