Open jonasstein opened 7 years ago
koppor
commented
7 years ago 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
commented
7 years ago 
notuntoward
commented
7 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
3 years ago 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
¹ 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.
ThiloteE
commented
2 years ago f7648e82168e180f635b0e783262117d75c87fa5 introduced multiple backup files (10 to be exact), but the problem here is still valid:
koppor
commented
1 year ago The current dialog reads as follows:
yenniejunvu
commented
1 year ago Hi! Is this issue still available? If so, can I try it?
koppor
commented
1 year ago Sure, I assigned you @yenniejunvu
github-actions[bot]
commented
1 year ago As a general advice for newcomers: check out Contributing for a start. Also, guidelines for setting up a local workspace is worth having a look at.
Feel free to ask here at GitHub, if you have any issue related questions. If you have questions about how to setup your workspace use JabRef's Gitter chat. Try to open a (draft) pull-request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.
koppor
commented
1 year ago Note that this issue also requires thinking of the cases which can happen and the respective UI. In other words: Do a proper Software Engineering requirements engineering.
gnandini156
commented
8 months ago Hi @jonasstein can you please provide me the steps to get a popup for a backup found .
ThiloteE
commented
8 months ago @gnandini156
To trigger the popup:
ThiloteE
commented
8 months ago See also https://docs.jabref.org/advanced/autosave for where backups are stored
KotalaRadhika
commented
7 months ago Hi @jonasstein @koppor
Could you please elaborate what to be fixed here?
i'm getting below popup
Also all 3 buttons are working fine.
koppor
commented
7 months ago @KotalaRadhika Good to see that you could bring up the dialog. Sadly, you did not show what happens at "Review backup"
Now, let's walk through the original posters steps.
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.
This is a general remark. Fortunately, the reporter refined it.
A few ideas how to help the user:
Heading for the following list. OK, let's read on.
name the backup file literature.bib.sav for example, so that the user can look for it
This is already done. We see it in blue in the dialog.
will recover overwrite the .bib file?
By the button "Review backup", the next step should be clear
will the .bib.sav be deleted, if NO is selected?
It should also be clear with the buttons. Hopefully
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
This should be in the dialog.
| Property | Current file | Backup file |
|---|---|---|
| Name | bug_reproduce.bib | ...07.bak |
| Size | 100kb | 0kb |
| Date | 2024-02-22 10:05 | 2024-02-21 23:49 |
| Number of entries | 100 | 95 |
| Changes | - | removed: 7, added: 2, modified: 3 |
That information should be put into the dialog. I think, this is possible using the Bibdatabase Diff. -- The numbers for "Number of entries" and "Changes" should be calculated in a Background Task, because for large files, this could take time.
No need for place holders. Pass first the backup file and then the .bib file.
The default tool is git diff --no-index (see https://stackoverflow.com/a/17194704/873282)
if the user can not answer this question now, give a chance to cancel.
I think, with "Ignore Backup" this is fulfilled.
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.
Also done with "Ignore Backup"
Hope, this helps
In general, the issue refs This somehow refs https://github.com/JabRef/jabref/issues/10853.
.
koppor
commented
3 weeks ago Even more refined: https://github.com/JabRef/jabref/issues/11454#issuecomment-2353703805
koppor
commented
2 weeks ago Technical hint: Use git and appdirs.
.bak file (even with git-bundle): Not good, because if used on Dropbox, conflicts may arise.git allows for "removing" intermediate backupsrcs: There is no good Java support - and squashing revisions is not supported.
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: