When saving: The libary has been modified by another program

JoKalliauer commented 5 years ago

Edit: JabRef 5.0, 5.1, 5.2, 5.4 till current version (Nov2021) is affected.

If you add a comment please add

your operating system
encoding of the document (e.g. ASCII, ANSI, ISO-8859, UTF-16 , ...)
the line-seperators used in the file (lineforward or cariage-return or both or mixed)
the settings of Options > Preferences > File -- (a) Newline seperator (try LineForward) -- (b) Always reformat BIB file on save and export (try disabling) -- (c) Autosave local libraries (try disabling)

Original post

JabRef 5.0-dev--snapshot--2019-04-09--master--0dd091f31
Linux 4.15.0-47-generic amd64 
Java 1.8.0_201

Ubuntu 18.04

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

Steps to reproduce the behavior: (same as #4810 )

open .bib-file
press "ctrl" & "s"
Repeat step 2 till Bug appears.
The message "The library has been modified by another program" appears
DO NOT accept the changes, otherwise all entries will be doubled (click dismiss)

Log File

``` Opening: /home/jkalliau/Desktop/Jabrefissue/LargeFile.bib Can only load style files: Preview Vorschaustil geändert zu: Vorschau Speichere Bibliothek... Opening: /tmp/jabref2591679195168273738.bib Opening: /home/jkalliau/Desktop/Jabrefissue/LargeFile.bib Bibliothek gespeichert '/home/jkalliau/Desktop/Jabrefissue/LargeFile.bib'. ```

Terminal

``` 16:45:54.405 [JavaFX Application Thread] INFO org.jabref.logic.importer.OpenDatabase - Opening: /home/jkalliau/Desktop/Jabrefissue/LargeFile.bib 16:45:54.963 [JavaFX Application Thread] ERROR org.jabref.logic.citationstyle.CitationStyle - Can only load style files: Preview 16:45:55.220 [JavaFX Application Thread] INFO org.jabref.gui.FXDialogService - Vorschaustil geändert zu: Vorschau 16:46:06.495 [JavaFX Application Thread] INFO org.jabref.gui.FXDialogService - Speichere Bibliothek... 16:46:06.524 [pool-3-thread-2] INFO org.jabref.logic.importer.OpenDatabase - Opening: /tmp/jabref2591679195168273738.bib 16:46:06.526 [pool-3-thread-2] INFO org.jabref.logic.importer.OpenDatabase - Opening: /home/jkalliau/Desktop/Jabrefissue/LargeFile.bib 16:46:06.530 [JavaFX Application Thread] INFO org.jabref.gui.FXDialogService - Bibliothek gespeichert '/home/jkalliau/Desktop/Jabrefissue/LargeFile.bib'. 16:53:39.039 [JavaFX Application Thread] INFO org.jabref.gui.FXDialogService - In die Zwischenablage kopiert ```

bernhard-kleine commented 5 years ago

This is most interesting since you work with Linux. Obviously the error is indepent of the operation system.

wujastyk commented 5 years ago

Me too. :-(

wujastyk commented 5 years ago

Could this be something to do with Dropbox? I guess the Dropbox application (nemo-dropbox in Linux Mint) runs some kind of file-checking background task, and maybe JabRef is sensing that?

Is anyone who sees this "library modified" popup behaviour not run Dropbox?

JoKalliauer commented 5 years ago

@wujastyk : I storred it locally on the desktop, therefore it is not reletated to any sync-program. Please also read @bernhard-kleine : comment: https://github.com/JabRef/jabref/issues/4810#issuecomment-477078401

wujastyk commented 5 years ago

I see. So it's not Dropbox. Thanks!

On Sun, 12 May 2019 at 01:49, Johannes Kalliauer notifications@github.com wrote:

@wujastyk https://github.com/wujastyk : I storred it locally on the desktop, therefore it is not reletated to any sync-program. Please also read @bernhard-kleine https://github.com/bernhard-kleine : comment: #4810 (comment) https://github.com/JabRef/jabref/issues/4810#issuecomment-477078401

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JabRef/jabref/issues/4877#issuecomment-491573552, or mute the thread https://github.com/notifications/unsubscribe-auth/AAF2DBWFGGV2SY5NX2KCRB3PU7DZ7ANCNFSM4HES3FEQ .

sfo commented 5 years ago

I can confirm this issue. It appears for files outside Dropbox, as well as for files within Dropbox and paused synchronization.

For me, it is independent from timing. I have the files on SSD. After editing, no matter how long, I save the file and the message appears.

JabRef 5.0-dev--snapshot--2019-06-10--master--eb42850f7 Linux 4.4.0-150-generic amd64 Java 1.8.0_212 Ubuntu 16.04

JoKalliauer commented 5 years ago

@sfo: How large is your libary? (filesize/entries)

wujastyk commented 5 years ago

Over 4000

Sent from Android phone

On Wed, 12 Jun 2019, 00:41 Johannes Kalliauer, notifications@github.com wrote:

@sfo https://github.com/sfo: How large is your libary? (filesize/entries)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JabRef/jabref/issues/4877?email_source=notifications&email_token=AAF2DBXIPMGGK4K4XISPDO3P2CLCPA5CNFSM4HES3FE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPNDGI#issuecomment-501141913, or mute the thread https://github.com/notifications/unsubscribe-auth/AAF2DBUXPZFAO5457T7VPE3P2CLCPANCNFSM4HES3FEQ .

sfo commented 5 years ago

@JoKalliauer here is a minimum working example:

% Encoding: UTF-8

@Article{,
}

@Comment{jabref-meta: databaseType:biblatex;}

gitcanzo commented 4 years ago

Same issue here (also using Jabref 5.0-dev). The message appears every time I save my library (even if no changes have been made). I do not have a big library, just about 100 entries. If I save the changes, all my entries are duplicated. My bib file is on a cloud folder (MEGA cloud, although that does not seem to be the issue). I am running Ubuntu Mate 19.04

Siedlerchr commented 4 years ago

Please check if you any save actions (library properties) or autosave enabled (preferences)

gitcanzo commented 4 years ago

Please check if you any save actions (library properties) or autosave enabled (preferences)

Both save actions and autosave are disabled. The issue persists

AEgit commented 4 years ago

JabRef 5.0-dev Linux 5.0.0-27-generic amd64 Java 1.8.0_222

Can confirm this issue using the minimum example provided here (https://github.com/JabRef/jabref/issues/4877#issuecomment-501544917) by @sfo

"Save actions" are NOT enabled. "Autosave" is also NOT enabled.

Since the minimum example contains just one entry and I have stored the database on a fast M.2 SSD, this issue does not seem to be related to the size of the database or slow hardware.

AEgit commented 4 years ago

JabRef 5.0-dev Linux 5.0.0-27-generic amd64 Java 11.0.4

Can confirm that this is still an issue with the current --edge snap version using Java 11 (I am just reporting this in case someone thought the switch to Java 11 had solved the problem). The minimum working example of @sfo (https://github.com/JabRef/jabref/issues/4877#issuecomment-501544917) is enough to be able to trigger this problematic behaviour.

koppor commented 4 years ago

Refs https://github.com/JabRef/jabref/issues/5085

Krzmbrzl commented 4 years ago

JabRef 5.0.0-dev--2019-10-25----681d6aa6f
Linux 5.0.0-32-generic amd64 
Java 12.0.2

I can also confirm the bug. Happens every time to me though. If I can help by providing more information, just state what you'd need :)

koppor commented 4 years ago

@Krzmbrzl Thank you for the feedback and offer. I have a long-termin solution in my mind (see https://github.com/JabRef/jabref/issues/5257#issuecomment-532958631), but currently did not find the time to do it.

tobiasdiez commented 4 years ago

@Krzmbrzl you have coding experience, right? This bug is a bit hard to fix for us since non of the core developers can reproduce it. So it would be nice if you could try to debug it and find the origin of the problem (and in the best case also provide a solution).

Krzmbrzl commented 4 years ago

I do. However I am very busy atm and I'm afraid won't find the time necessary to do so properly... Plus I think I can't even set it up on my machine as I don't have JDK 12 available on my system

tobiasdiez commented 4 years ago

Sure, no problem. In case you find bit of time, you find everything that you need to setup the build locally here: https://github.com/JabRef/jabref/wiki/Guidelines-for-setting-up-a-local-workspace

reox commented 4 years ago

I have this issue too:

JabRef 5.0.0-dev--2019-10-25----b8d00f2bd
Linux 5.2.0-3-amd64 amd64 
Java 12.0.2

unfortunately I dont see any log output, as the debian package from the snapshots does not ship with log4j:

ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...

I suspected that maybe the noatime flag on my filesystem might causing this, but I verified on another filesystem with relatime that I get this message too.

JoKalliauer commented 4 years ago

@Krzmbrzl you have coding experience, right? This bug is a bit hard to fix for us since non of the core developers can reproduce it. So it would be nice if you could try to debug it and find the origin of the problem (and in the best case also provide a solution).

As a provisional workaround you can just add a button in the preferences to dissable the changes-feature.

koppor commented 4 years ago

00:03:19.723 [pool-9-thread-1] ERROR org.jabref.logic.autosaveandbackup.BackupManager - Error while saving to fileC:\TEMP\del.me.bib.sav
java.nio.file.FileSystemException: C:\TEMP\del.me.bib.sav -> C:\TEMP\del.me.bib.sav.bak: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

We should remove the sav and bak feature. This is so 2000. I forced to keep it in 2015, but I regret it now. Version control and backup feature are now common things.

Maybe, if we just remove bak and sav (and directly save to bib), all these change detection issues could be resolved.

tobiasdiez commented 4 years ago

I think this issue is a direct consequence of #5257. The user saves the library, which changes the file, which leads JabRef to check for changes. Normally, there are none (as the user just saved) but due to the bug #5257 JabRef thinks that every entry changed. (This also explains why accepting the changes, all entries are duplicated.)

Concerning the backup feature, I agree the sav file is not needed and does not really add any value. I would replace it with a very simple minded backup strategy: whenever the user opens a bib file, create a copy of that file in the systems temporary folder. Keep at max 10 copies. In this way users that don't use version control / manual backup solutions still have the possibility to go back in time, at least a bit. The following might be helpful: https://github.com/bmc/javautil/blob/master/src/main/java/org/clapper/util/io/RollingFileWriter.java

koppor commented 4 years ago

Note to self: We really need .bak because of AtomicFileOutputStream.

tobiasdiez commented 4 years ago

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.

bernhard-kleine commented 4 years ago

Testing the new version I notices two errors: What I did: Opening the file; Save it immediately by Ctrl-S Adding Color to a group Saving the file again.

The log is from the command line which still shows in a separate window with "ERROR StatusLogger Log4j2 could not find", the log event in HELP->View Event Log is empty.

`ERROR SaveDatabaseAction A problem occurred when trying to save the file K:\BuchprojektSpringer\VierteAuflage\Literatur\ EndokrinologieKunde20190320VS5.0.bib org.jabref.logic.exporter.SaveException: Problems saving: at org.jabref/org.jabref.gui.exporter.SaveDatabaseAction.saveDatabase(Unknown Source) at org.jabref/org.jabref.gui.exporter.SaveDatabaseAction.doSave(Unknown Source) at org.jabref/org.jabref.gui.exporter.SaveDatabaseAction.save(Unknown Source) at org.jabref/org.jabref.gui.dialogs.AutosaveUIManager.listen(Unknown Source) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber$SynchronizedSubscriber.invokeSubscriberMethod( Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber$1.run(Unknown Source) at org.jabref.merged.module/com.google.common.util.concurrent.DirectExecutor.execute(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber.dispatchEvent(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Dispatcher$PerThreadQueuedDispatcher.dispatch(Unknown Sou rce) at org.jabref.merged.module/com.google.common.eventbus.EventBus.post(Unknown Source) at org.jabref/org.jabref.logic.autosaveandbackup.AutosaveManager.lambda$listen$0(Unknown Source) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Caused by: java.nio.file.AccessDeniedException: K:\BuchprojektSpringer\VierteAuflage\Literatur\EndokrinologieKunde201903 20VS5.0.bib.tmp -> K:\BuchprojektSpringer\VierteAuflage\Literatur\EndokrinologieKunde20190320VS5.0.bib at java.base/sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at java.base/sun.nio.fs.WindowsFileCopy.move(Unknown Source) at java.base/sun.nio.fs.WindowsFileSystemProvider.move(Unknown Source) at java.base/java.nio.file.Files.move(Unknown Source) at org.jabref/org.jabref.logic.exporter.AtomicFileOutputStream.close(Unknown Source) at java.base/sun.nio.cs.StreamEncoder.implClose(Unknown Source) at java.base/sun.nio.cs.StreamEncoder.close(Unknown Source) at java.base/java.io.OutputStreamWriter.close(Unknown Source) at org.jabref/org.jabref.logic.exporter.BibDatabaseWriter.savePartOfDatabase(Unknown Source) at org.jabref/org.jabref.logic.exporter.BibDatabaseWriter.saveDatabase(Unknown Source) ... 21 more ERROR AutosaveUIManager Problem occurred while saving. java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-5-thread-1 at org.jabref.merged.module/com.sun.javafx.tk.Toolkit.checkFxUserThread(Unknown Source) at org.jabref.merged.module/com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(Unknown Source) at org.jabref.merged.module/javafx.stage.Stage.(Unknown Source) at org.jabref.merged.module/javafx.stage.Stage.(Unknown Source) at org.jabref.merged.module/javafx.scene.control.HeavyweightDialog$1.(Unknown Source) at org.jabref.merged.module/javafx.scene.control.HeavyweightDialog.(Unknown Source) at org.jabref.merged.module/javafx.scene.control.Dialog.(Unknown Source) at org.jabref.merged.module/org.controlsfx.dialog.ExceptionDialog.(Unknown Source) at org.jabref/org.jabref.gui.JabRefDialogService.showErrorDialogAndWait(Unknown Source) at org.jabref/org.jabref.gui.exporter.SaveDatabaseAction.doSave(Unknown Source) at org.jabref/org.jabref.gui.exporter.SaveDatabaseAction.save(Unknown Source) at org.jabref/org.jabref.gui.dialogs.AutosaveUIManager.listen(Unknown Source) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber$SynchronizedSubscriber.invokeSubscriberMethod( Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber$1.run(Unknown Source) at org.jabref.merged.module/com.google.common.util.concurrent.DirectExecutor.execute(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Subscriber.dispatchEvent(Unknown Source) at org.jabref.merged.module/com.google.common.eventbus.Dispatcher$PerThreadQueuedDispatcher.dispatch(Unknown Sou rce) at org.jabref.merged.module/com.google.common.eventbus.EventBus.post(Unknown Source) at org.jabref/org.jabref.logic.autosaveandbackup.AutosaveManager.lambda$listen$0(Unknown Source) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source)

`

wujastyk commented 4 years ago

I just fetched

JabRef 5.0.0-dev--2019-11-28----ce0e8870c Linux 5.3.0-23-generic amd64 Java 13.0.1

from the master builds,
made a small change
hit "save"
and still had the old error

But maybe I need to wait a little longer before fetching a new master build?

AEgit commented 4 years ago

JabRef 5.0.0-dev--2019-11-28----ce0e8870c Windows 10 10.0 amd64 Java 13.0.1

Using the minimum example provided by @sfo in https://github.com/JabRef/jabref/issues/4877#issuecomment-501544917 I can confirm that this issue has been solved.

So far I have not been able to reproduce the issue reported by @wujastyk in https://github.com/JabRef/jabref/issues/4877#issuecomment-559610890

I was also not able to reproduce the behaviour that @bernhard-kleine mentioned in https://github.com/JabRef/jabref/issues/4877#issuecomment-559607391, but since this issue appears to be difficult to reproduce (you have to save "immediately") this might be to be expected. What I did notice, though, when trying to reproduce https://github.com/JabRef/jabref/issues/4877#issuecomment-559607391 was that the CPU usage shot up to 100% on a 6-core machine when modifying the colour of a group (database with nearly 20,000 entries; group contains several hundreds of entries) to the point that JabRef appeared to have crashed when trying to save. This problem however, might be more of a performance issue, and is possibly related to what has been reported here: https://github.com/JabRef/jabref/issues/5071#issuecomment-554769666

wujastyk commented 4 years ago

JabRef 5.0.0-dev--2019-11-29----ea5e632e4 Linux 5.3.0-23-generic amd64 Java 13.0.1

Still getting it :-(

matthiasgeiger commented 4 years ago

@wujastyk Above you mentioned that you are using Dropbox to synchronize. Can you please check whether this problem is also happening in a folder that is not synced?

Thanks!

AEgit commented 4 years ago

@wujastyk Does it happen with your own database or can you reproduce the issue also with the minimum example provided in https://github.com/JabRef/jabref/issues/4877#issuecomment-501544917? If the former is the case, the problem might be related to the size of the database and/or the speed of your storage device. If the latter is the case, then the issue probably has not been solved.

wujastyk commented 4 years ago

JabRef 5.0.0-dev--2019-11-29----ea5e632e4 Linux 5.3.0-23-generic amd64 Java 13.0.1

Yes, I'm afraid it still happens even when I switch off Dropbox.

[image: image.png]

reox commented 4 years ago

I still have the same problem with my bib file (~850 entries, on ext4 (rw,noatime,nodiratime,discard) filesystem locally) but not with the minimal example.

JabRef 5.0.0-dev--2019-11-30----e251de5c5
Linux 5.3.0-2-amd64 amd64 
Java 13.0.1

wujastyk commented 4 years ago

I should have said: I'm testing on a large database too. Ca. 4000. Does size ever matter?

On Sat, 30 Nov 2019 at 07:55, reox notifications@github.com wrote:

I still have the same problem with my bib file (~850 entries) but not with the minimal example.

JabRef 5.0.0-dev--2019-11-30----e251de5c5 Linux 5.3.0-2-amd64 amd64 Java 13.0.1

bernhard-kleine commented 4 years ago

JabRef 5.0.0-dev--2019-11-28----ce0e8870c Windows 7 6.1 amd64 Java 13.0.1

For me the error "the library has been changed" is gone. The actual library has 2800+ entries.

reox commented 4 years ago

Maybe its a linux or filesystem thing? on

JabRef 5.0.0-dev--2019-11-28----ce0e8870c
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 13.0.1

I still have the problem. Here the bib file is on NFS.

AEgit commented 4 years ago

@reox Do you also have the problem with the minimum example file (https://github.com/JabRef/jabref/issues/4877#issuecomment-501544917)? Or is it your own (larger?) library?

reox commented 4 years ago

@AEgit I tried on this PC also: No, with the minimal example I do not have the problem.

wujastyk commented 4 years ago

JabRef 5.0.0-dev--2019-12-02----9d620f18d Linux 5.3.0-23-generic amd64 Java 13.0.1

Still there for me, unfortunately.

bernhard-kleine commented 4 years ago

My claim that the error is gone, was wrong: In the dark scheme it was not obvious, but is still there.

tobiasdiez commented 4 years ago

So let's be systematic about it (most of us are scientist, so why not try to actually apply what we teach students ;-) ). As this will involve a bit of playing around with your file, please make sure to make a backup before.

Can you always replicate the bug with your database?
With the minimal example above?
On which OS? Linux or Windows? Or both?
Does it matter where the database is saved?
Does it also occur if you choose "Save as" and write the file to somewhere else?
If you choose "Save as" but overwrite the original file?
Are only entries concerned, or also other data in the library? (Try to add Strings, Preamble and change a few settings under Library properties. Save, close JabRef, open again and experiment now with saving).
What kind of changes are exactly reported? (Screenshot of the dialag is best)
Does the change detection work in principle (to test: open JabRef, open file in a text editor, change something and save there -> JabRef now should report only this single change).

Thanks for your help! Depending on the answers to these questions, I'll try to find the origin of the issue or at least add more debugging output that should pinpoint the exact location.

bernhard-kleine commented 4 years ago

I copied one entry of my library into a fresh library. I saved it as test.bib. I added a date and saved it again. The error appeared. This is really a minimal example. JabRef 5.0.0-dev--2019-11-28----ce0e8870c Windows 7 6.1 amd64 Java 13.0.1

The article in question:

@Article{TW18,
  author          = {Tabuchi, Masashi and Wu, Mark N.},
  date            = {2019-09-03},
  year            = {2018},
  title           = {Sleep: Setting the 'Circadian' Alarm Clock.},
  abstract        = {How the circadian clock regulates downstream behaviors, such as sleep, remains poorly understood. A new study reveals that clock-dependent downscaling of GABA sensitivity of arousal neurons promotes wakefulness at dawn.},
  doi             = {10.1016/j.cub.2017.11.011},
  issn            = {1879-0445},
  issue           = {1},
  month           = jan,
  pages           = {R26--R28},
  volume          = {28},
  chemicals       = {Receptors, GABA-A},
  citation-subset = {IM},
  completed       = {2019-01-30},
  country         = {England},
  file            = {:CircadianClock/CurrBiol_28_R17_Tabuchi_Sleep__Setting the 'Circadian' Alarm Clock.pdf:PDF},
  issn-linking    = {0960-9822},
  journal         = {Current biology},
  keywords        = {Circadian Clocks; Circadian Rhythm; Receptors, GABA-A; Sleep; Wakefulness},
  nlm-id          = {9107782},
  owner           = {NLM},
  pii             = {S0960-9822(17)31456-2},
  pmid            = {29316417},
  pubmodel        = {Print},
  pubstatus       = {ppublish},
  revised         = {2019-01-30},
  timestamp       = {2019.04.15},
}

tobiasdiez commented 4 years ago

@bernhard-kleine can you please answer my questions above? None of the core developers can reproduce the problem, which makes this issue particularly difficult to fix (its like finding a needle in a haystack, but without looking). We want to fix it, but we really need your help for this!

bernhard-kleine commented 4 years ago

no
no
on win7
when I save the minimal file to another dir, it works without error. Upon resaving, the error reappears.
no see 4)
no
I added a group, the error was gone, it is a chamaeleon,
see screenshot.
I changed the timestamp in the editor. Jabref informs about the change but does not pinpoint it in the dialog box

I hope this helps, I am not sure myself.

tobiasdiez commented 4 years ago

Thanks! How does the dialog look like when the bug occurs? Does it also says added and removed entry, both being empty?

reox commented 4 years ago

scarifice my .bib for the science :D

1. Can you always replicate the bug with your database?

yes. Both on CentOS and Debian. Pressing Ctrl+S triggers it. Also pressing like Alt+F8 triggers it. (Did not test others, but I'm pretty sure other actions do this as well)

2. With the minimal example above?

No, the empty database does nothing.

3. On which OS? Linux or Windows? Or both?

I only have CentOS and Debian machines here :(

4. Does it matter where the database is saved?

Currently the library is saved on a ext4 with the following options: rw,noatime,nodiratime,discard

Then, I created a ramdisk and opened the database there, same problem (ext4 on /mnt/test type tmpfs (rw,relatime,size=4194304k))

I also tried another fs (xfs on /mnt/test2 type tmpfs (rw,relatime,size=4194304k)), same result.

5. Does it also occur if you choose "Save as" and write the file to somewhere else?

Saved library as foobar.bib. Save was successful. Press Ctrl+S, triggers the bug.

6. If you choose "Save as" but overwrite the original file?

Again, save is successful, but a Ctrl+S triggers.

7. Are only entries concerned, or also other data in the library? (Try to add Strings, Preamble and change a few settings under Library properties. Save, close JabRef, open again and experiment now with saving).

So, I created a empty new database. Pressed Ctrl+S and it shows the message...

Backuped all preferneces:

$ cd $HOME
$ mv .org.jabref.JabRefMain{,.BACKUP}
$ mv .java{,.BACKUP}

Opened up Jabref, created a new database, press Ctrl+S -> still triggers.

8. What kind of changes are exactly reported? (Screenshot of the dialag is best)

Tested on the freshly created library from above, with completely new configuration. Actually, None: 2019-12-02-185052_1309x789_scrot

9. Does the change detection work in principle (to test: open JabRef, open file in a text editor, change something and save there -> JabRef now should report only this single change).

Again on the same database: Add the article from the comments (TW18) Additionally to the Metadata change, I get a Added Entry. The Text is empty though. Should it show the article? 2019-12-02-185314_822x641_scrot

I accept the change and see the article in the list.

Interestingly, pressing now Ctrl+S does not trigger the bug! I can do whatever I want now and it does not trigger. I also enabled autosave now, and it still does not trigger.

Now, I add a newline in the file - there is now warning of a changed file. If I press Ctrl+S now, the file is simply overwritten.

I duplicated the article in the bib file, and changed just the biblatexkey - this triggers the change warning and will correctly show an added article - again without text. Again, I can now do whatever I want - it will not trigger the warning.

Now, back to my library file. I have the portable config mode enabled, so I started it up from the directory with the config file and see my library. Pressing Ctrl+S triggers it and it shows me three changed entries: 2019-12-02-190024_812x632_scrot

even more weird, it shows me the change... So in this case, I accept the three changes. Even more interestingly: the bib file is not changed (checked via git) AND pressing Ctrl+S now does not trigger the bug!

Hope that helps!

edit: wait, there is more. I closed Jabref. removed the .bak file. Open it again. and press Ctrl+S. I again see the change warning with the same entries from above with the same changes. I accept them again. The bib file is not changed... And again, the message will not re-appear. I now had a look into my library: In the case of Ferrari2019, the skimmed attribute is not in the keywords, maybe this is the problem?

[...]
  keywords     = {prio3, rank3},
  priority     = {prio3},
  publisher    = {Wiley},
  ranking      = {rank3},
  readstatus   = {skimmed},
  timestamp    = {2019-10-26 10:57},
[...]

For Kersh2013, the priority is not synced with the keywords - which is also the offending change and for Chavassieux2019, it is indeed also the skimmed attribute which is not in the keywords.

So I disabled the syncing of the special fields, and indeed the problem went away :open_mouth:

edit edit: Oh no :disappointed: I just started a cleanup task and immediately got the warning. Only two entries were changed in the cleanup, and even here only the comment field was reformatted. But all the "changes" are replaced chars: 2019-12-02-191440_563x178_scrot

bernhard-kleine commented 4 years ago

@tobiasdiez I have never seen any data in this dialog box.

reox commented 4 years ago

I also tested this now on the CentOS machine and can replicate the behaviour there as well:

When I start up JabRef, it shows me the readstatus/priority changes, if I accept them, there are no further messages when manually saving
But if I restart JabRef, it will complain about the same entries again.
Or I can get rid of this message for ever by disabling the keyword sync
If I start a cleanup on a entry where there is a \& in some field (for example the journal), it will warn about the change (external: \&, current: &)
Even though I dismiss the change, JabRef will show me the "corrected" version & in the UI, but will not write the change to the bib file.
If I accept the change, it will show \& in the UI again

JabRef 5.0.0-dev--2019-11-28----ce0e8870c
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 13.0.1

tobiasdiez commented 4 years ago

Perfect, I think I know now the reason for this bug. Fix should be coming in the next few days!

JabRef / jabref

When saving: The libary has been modified by another program #4877