Restore from Backup triggered unnecessarily

[ThiloteE]

Follow up issue to #9361

JabRef version

5.8 (latest release)

Operating system

Windows

Details on version and operating system

JabRef 5.8--2022-12-18--b7fae4b Windows 10 10.0 amd64 Java 18.0.2.1 JavaFX 19+11

Checked with the latest development build

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. Have a library with entries. Save.
2. Close JabRef
3. Open JabRef
4. Do NOTHING, except waiting a little
5. Close JabRef without saving
6. Open JabRef

Result:
Backup found dialogue triggers

Expected result:
Backup found dialogue should not trigger

[jelasity]

I have the same issue, this backup dialog pops up all the time.

JabRef 5.9--2023-01-08--76253f1a7
Linux 5.19.0-32-generic amd64
Java 19.0.1
JavaFX 19+11

[ThiloteE]

Meanwhile, I found old leftover .sav and .bak files in my folders with the library files. I removed all of those and I think, since then I do not regularly experience the popup anymore. @jelasity, please check your folders for these files (please create a backup of them first!) and delete them. JabRef since version 5.8 stores .bak files in a separate dedicated directory.

Edit: One of my next personal projects is Update info about backup manager and .sav and .bak files in docs

[jelasity]

Actually, in my case the backup is in the directory

./snap/jabref/2265/.local/share/JabRef/5.9--2023-01-08--76253f1a7/backups/

and for some reason it gets generated quite frequently. If I remove all the backups, start jabref, wait a few seconds, do a ctrl-q, then there is a backup again, and the warning, when I start next time.

[ThiloteE]

yes, this is intended. Since 5.8, JabRef creates a new backup every 15 20 seconds (i believe it was 15? it was 15 seconds pre 5.8, but after the rework it's now 20!) after there was a change to your library in this special folder. JabRef stores up to 10 automatic backups in this folder. It depends on your Operating System and apparently on your version of JabRef where this special folder is located.

Only, if you find backup files somewhere in other folders, you probably should tidy them up.

[ThiloteE]

Have there been any changes to your library though? Is your library file shared to remote (online) devices via cloud?

Edit: Sorry, gotta go offline now. Will be online again later today.

[jelasity]

No, the backups are created even without any active changes. The library is not shared. The problem is not with the existence of the backups, but with the waring, that jabref was not shut down cleanly (which is not true). It is a bit annoying having to start every session with clicking on "ignore backup".

[koppor]

@jelasity To dig deeper into this:

I assume, the .bib file was originally created by another tool (or manually)?

• Is it possible for you to make a diff between the backup file and the original .bib file?
• What does JabRef show if you click on "Review backup"?
  

[jelasity]

Actually, the phenomenon has become less frequent these days. It still happens, but more rarely. For example, right now I'm not able to reproduce this. It probably depends on something I do but I'm not sure what exactly.

The bib file has been in use for more than three years and I never edit it directly, only through jabref. It contains some 2000 entries. Most entries with linked pdfs, and also group information. My guess is that under some circumstances jabref feels it was not shut down properly when in reality it was. It might have to do with background processes (for example, maybe when I shut the OS down after cleanly closing the GUI but with jabref still in the background (eg choking on some big pdf or something)).

If it happens again, I will collect the data you requested.

[ThiloteE]

@jelasity If you cannot find anything with 5.9, you could try the newest development version of JabRef instead. Maybe it helps. You can download it from here. Meanwhile, there have been some further improvements to the UI of the "Review Backup" dialogue, which now also shows a more sophisticated "entry preview" and the "bibtex source" tab.

[koppor]

Actually, the phenomenon has become less frequent these days. It still happens, but more rarely.

Please, in the case, it happens, please copy the .bib and the latest .bak file to a separate directory.

The bib file has been in use for more than three years and I never edit it directly, only through jabref.

Thank you for that 🤩

My guess is that under some circumstances jabref feels it was not shut down properly when in reality it was. It might have to do with background processes (for example, maybe when I shut the OS down after cleanly closing the GUI but with jabref still in the background (eg choking on some big pdf or something)).

When JabRef loads, it does a binary compare on the .bib and .bak file. If there is a mismatch, the dialog is started. Thus, there is a change (for JabRef). Alternatively, it might be the case that the previous checks do not run through properly.

In the directory %APPDATA%\..\Local\org.jabref\jabref\logs, you will find directories with logs.

Please try the binary especially crafted for you - it is available at https://builds.jabref.org/pull/9680/merge/.

[koppor]

Code comment: This is caused by

jabref/src/main/java/org/jabref/logic/importer/fileformat/BibtexParser.java

Line 285 in 92aee56

parserResult.addWarning(Localization.lang("Error occurred when parsing entry") + ": '" + ex.getMessage()

. I wonder why the parser result is not displayed to the user. Think, we need to work on that (if JabRef reads a file from disk). Could be more complicated though.

[jelasity]

When JabRef loads, it does a binary compare on the .bib and .bak file. If there is a mismatch, the dialog is started. Thus, there is a change (for JabRef). Alternatively, it might be the case that the previous checks do not run through properly.

I tested this a bit, and it looks to me that the dialog is started only if two conditions are both met: the files differ and the bib file is older than the bak file. Now, I work at two locations and synchronize my working directories with rsync., but I do not synchronize the jabref directories (where the .bak files are stored, for example). But this should cause no problem because both computers have correct timestamps and so the timestamp of every bib file can only move forward, while the .bak files are not affected by rsync. If I synchronize while jabref is running, a newer .bak file can be written using the old data. However, I tested this too and jabref warns me that the library was modified, and I don't remember seeing that before.

In any case, if this happens again, I now know where to look for causes, and I will get back to you.

[koppor]

When JabRef loads, it does a binary compare on the .bib and .bak file. If there is a mismatch, the dialog is started. Thus, there is a change (for JabRef). Alternatively, it might be the case that the previous checks do not run through properly.
I tested this a bit, and it looks to me that the dialog is started only if two conditions are both met: the files differ and the bib file is older than the bak file.

This is exactly the condition, JabRef implements.

In other words: JabRef continuously writes .bak files. In case JabRef crashes, the written .bak file is newer than the saved .bib file. Then, the dialog appears. However, this dialog does not need to appear if there is no content difference.

Note that we also implement "discarded" if a user discards new changes: #9361

Now, I work at two locations and synchronize my working directories with rsync., but I do not synchronize the jabref directories (where the .bak files are stored, for example). But this should cause no problem because both computers have correct timestamps and so the timestamp of every bib file can only move forward, while the .bak files are not affected by rsync. If I synchronize while jabref is running, a newer .bak file can be written using the old data.

Ah, yes. And this could be the reason of the warning?

I need to think more of that.

Keywords:

• .bib v1 is written as .bak
• .bib v2 is created using rsync
• JabRef should notify "file changed on disk"?

In any case, if this happens again, I now know where to look for causes, and I will get back to you.

Thank you!

[jelasity]

I bumped into it again, and I debugged it a bit. The key seems to be this:

1: I'm adding a new entry, which is placed at the top of the bib file.
2: Then I close jabref, and when it asks me to save the library, I save it. Important: the saved library will begin with a linefeed character (hex 0A)
3: Next time I open jabref (and the library), all is fine. But then a bak is saved automatically, which does NOT contain the first linefeed character. And it will be newer than the library.
4: When I open jabref the second time, I get the "restore from backup" warning, because the files differ and the bak is newer.