Auto-backup issue on (slow) shared folder

[alfureu]

JabRef 5.2--2020-12-24--6a2a512
Windows 10 10.0 amd64
Java 14.0.2

• Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

If the .bib file is shared on Dropbox/OneDrive/WebDAV with a somewhat slower connection (i.e. slower than an SSD writing speed), the auto-backup feature reverts back to the backup version, losing the newly 'saved' file in the updated .bib file. I am using a stable version 5.2.

Steps to reproduce the behavior:

1. Open a bib file from Dropbox/OneDrive with 1000 entries
2. Create a new group, Add a new Entry and Save it
3. Close the file/tab
4. Observe the creation of filename.bib.bak, filename.bib.sav, and filename.bib.sav.tmp on the filesystem
5. Do not close JabRef, as within a minute the bib file will reopen (!!!) without any user interaction
6. The problem: the file is not the newly saved file with including the new entry, but the autosaved version without the new entry. I.e. if you save this file on closing, you are losing the new entry from the previous save without any warning.
7. If you reject this save, the tab with the file does not open anymore.

This is IMHO a serious bug, as one can lose entries. I checked the online documentation how things intend to work, however, this is somehow not ideal on shared drives I guess. Could you please investigate this further?

Besides the obvious bug or automatic reopening of the auto-backup file, I was wondering whether with large datasets (with 100s of entries) it would be advisable to inform the user on saving of some basic stats, i.e. about the change in total amount of entries, how many new entries are going to be saved, and how many entries were edited, eventually deleted. This should be doable as a result of comparing the auto-backup files with the newly saved one. With this approach it can be ensure that the user is fully informed and want to commit the changes.

[calixtus]

Maybe related to #5967 ?

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!

[ThiloteE]

@DOFfactory could you please test with the newest development version? Commit 6a71395 fixed a bug in the auto-save and f7648e8 made substantial changes to the backup manager (e.g. introduced 10 backups instead of just one)

[calixtus]

Closing this issue due to inactivity 💤
Please reopen the issue with additional information if the problem persists.