jabref
jabref copied to clipboard
Enhanced backup restore dialog
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.
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
Refs https://github.com/koppor/jabref/issues/149
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.
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?
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.
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.
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?
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.
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.
f7648e82168e180f635b0e783262117d75c87fa5 introduced multiple backup files (10 to be exact), but the problem here is still valid:
- Give user more information about these multiple backup files, so that
- they can choose the correct one to import,
- or dismiss importing altogether.
The current dialog reads as follows:
Hi! Is this issue still available? If so, can I try it?
Sure, I assigned you @yenniejunvu
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.
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.
Hi @jonasstein can you please provide me the steps to get a popup for a backup found .
@gnandini156
To trigger the popup:
- open/create a library with JabRef
- save said library
- Change something in the library, e.g. adding a comment or adding a new entry.
- Wait ~ 20 seconds for a backup to be created
- Close JabRef and the library WITHOUT saving.
- Open JabRef and said library again
- Now the popup should trigger.
See also https://docs.jabref.org/advanced/autosave for where backups are stored
Hi @jonasstein @koppor
Could you please elaborate what to be fixed here?
i'm getting below popup
Also all 3 buttons are working fine.
@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.
- [ ] A table
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.
- [ ] Moreover, launching directly an external diff tool would be great.
- New button "External diff" (that launches the diff tool)
- Let the tool be configured at "External programs"
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.
.