Don't ever overwrite or delete recover files

[unfa]

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]

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]

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

[zonkmachine]

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

[zonkmachine]

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]

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]

Closed via #2176