Enhanced backup restore dialog

[jonasstein]

This warning should tell the user exactly what the consequences of yes/no are. Some users want to create a backup or investigate the files manually, before answering the question.

A few ideas how to help the user:

• name the backup file literature.bib.sav for example, so that the user can look for it
• will recover overwrite the .bib file?
• will the .bib.sav be deleted, if NO is selected?
• what is the difference between the two files? size/date/number of entries/perhaps suggest the user to run a diff tool like diff or meld
• if the user can not answer this question now, give a chance to cancel.
• allow to ignore the question, if the user wants to start jabref and work on another file, but can not answer the recover question now.

[koppor]

Thank you for the long issue description including proposals. Can you create a pull request? 😇 In other dialogs we had a similar discussion. E.g., when closing a database with unsaved changes. @oscargus

[koppor]

Refs https://github.com/koppor/jabref/issues/149

[notuntoward]

I'll just add that I never used to see this popup but now see it all the time, whether or not I've saved the .bib file before exiting jabref.

[j0hannes]

Me too, almost every time I open JabRef the popup appears.

I'm usually clicking yes assuming that the backup file is a newer version of the bib file. I'm a right?

[chrisrapson]

I've noticed that the backup files (.bib.bak or .bib.sav) are often NOT newer than the .bib file. So I now open up my file manager, navigate to the folder and check the modification times before making my decision.

There are times when it's good to have a backup that's older than the .bib file, for example when I delete an entry by accident and want to recover it. But most of the time I want the most recent changes. So maybe a button that can expand the window with "details" like modification times would be useful. The window expansion could include the answers to jonasstein's other questions. Going further, a diff would be the ultimate way of knowing which file I want to use.

[koppor]

Really nice ideas! Could you offer some implementation help or know someone who could support us? 😇 We could arrange a JabRef hackday where some of our core developers are online for questions. In Germany, we have in Stuttgart a kind of development lab for an onsite hack event.

[chrisrapson]

I've got a bit much on for the next month or so, but if this is still open after that I might have a look at it. (I won't mind if someone jumps in and takes care of it before then!)

Quick related question: what is the reason for having a backup file and an autosave file?

[koppor]

The backup file is a relict from old JabRef times. The bak file was created before saving the database. The reason was to be be able to recover from failed saves. In 2016 we decided to keep this feature. However, none of the users reported broken bibliography files, so the bak feature can be removed when working on this. - We would be really happy if you found time this summer. Most of our developers are also online at https://gitter.im/JabRef/jabref so that we can answer questions there.

[pat-richter]

This issue still persists with JabRef 5.3. I get annoyed/irritated quite often, but still can't detect the issue behind.

A simple solution would be to add some more information (modification date), as already suggested.
Instead, I would like to see a third button.

Button 1: Use current file
Button 2: Use backup file
Button 3: Compare files

The third button should open the dialog which is also shown, when the file has been changed by an external program.

With this solution one could

• easily see whats going on (no more guessing) and then choose the right file
• also keep only some changes, e.g. when the last edit of the library file has lead to some confusion¹

¹ I've had some times, when I copyied and pasted the bibtex code, without changing the bibtex key. This has led to broken bib file. I currently have my bib in a dropbox. But also in a git repo (which allows my to compare to a previous version easily). I would like to dispense on that additional "backup" step.