Jabref reports inexistent changes

[j0hannes]

JabRef version 5.0-dev

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

Jabref frequently reports external changes although there have been none (I could find the corresponding bug report). Now, it also reports changed fields. However, both values are identical, e.g.

Modification of field: DATE
Value set externally: 1987
Current value: 1987
Modification of field: LOCATION
Value set externally: Stroudsburg, PA, USA
Current value: Stroudsburg, PA, USA

[koppor]

Refs #5085

[AEgit]

See also:
#4877
#4810

Might all represent the same bug (?).

[j0hannes]

What is new (the "changes" were empty before) is the information that e.g. the DATE changed from 1987 to 1987, which obviously is an error since it is the same value, that is, there was no change. So I'd reason that there is some error in the code. Maybe you monitor the inode of the bib file and when a change is reported you report back anything without checking values? Which still leaves to explore why there would be any change to the file at all, maybe atime changes as the file is indexed or accessed by other tools?

[Siedlerchr]

Yes, we do watch the directory for change as it's not possible to watch a single file change.
Do you have any other files in the same dir as the bib file? e.g. the pdfs?

https://github.com/JabRef/jabref/blob/0dd091f31b86b02dd9e44b4ac86aa204d4dec9ef/src/main/java/org/jabref/gui/util/DefaultFileUpdateMonitor.java

The bib files is compared entrywise in the ChangeScanner

[j0hannes]

Yes, I have several bib files in the same directory. But obviously I cannot change them simultaneously in Jabref. So once I (auto)save one bib file, all other open bib files in the same directory are checked for changes for each single entry? Why don't you look at mtime (and maybe file size) to see if there really has been a modification?

I would also guess that there is something wrong in the ChangeScanner since it reports 1987 and 1987 to be different values.

[Siedlerchr]

I could reproduce it somehow under linux:
This totally weird.

1. Open the library
2. Delete the sav and bak files
3. Save
4. Review changes pops up. All have the same value for author (e.g. a)
5. Change author to b
6. Value set externally = entered value = b, Current value = a, Current tmp value = a
7. Dismiss changes,
8. Hit save again, no changes popup
9. Modify author to c
10. Hit save
11. Review pops up: Value set externally = entered value =c, Current value = a, tmp = b
12. Hit accept changes
13. Save again
14. Review pops up: Value set externally = c, CurrentValue = c, tmp = a
15. Dismiss
16. Modify author to d
17. Review pops up: Value set externally = entered value =d , Current val = c, tmp val=c
18. Dimiss changes again
19. Change author to e
20. Review pops up: Value set externally = entered value = e, Current val = c, tmp val = d

---

[koppor]

Currently, JabRef does not store an in-memory copy of the loaded file (at the time of reading). Thus, when much is changed AND the file is changed on disk, sometimes, JabRef does not know, which part has really changed. In case the "original" version is stored, JabRef can be smarter. In other words: The user experience of http://help.jabref.org/en/SQLDatabase also has to work for local files. This would also fix #5085 and JabRef#273.

[koppor]

The implementation would be Optimistic Offline Lock.

[koppor]

We heared interest of a interested persons. If someone else wants to work on this issue, please report back to me.

[tobiasdiez]

@koppor are you or somebody else actively working on this?

[koppor]

I will ask at the back office.

[koppor]

Refs #5124. Fix could solve #156

[tobiasdiez]

Hopefully, this should be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks! Please remember to make a backup of your library before trying-out this version.

[JoKalliauer]

@koppor , @tobiasdiez Is it moved from "High priority" to "Closed" because it is a duplicate of #4877 (which is in "needs triage") or because you assumed it to be solved?

I just tried

JabRef 5.0-beta.1--2019-12-15--0b8b1d6
Linux 4.15.0-72-generic amd64
Java 13.0.1

and it still persits.

[tobiasdiez]

Originally, I'd hoped that this issue is fixed - but sadly its not. I think we only need one open issue for this, and as #4877 contains a lot of details this one is the canonical candidate.