jabref
jabref copied to clipboard
When saving: The libary has been modified by another program
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
This is most interesting since you work with Linux. Obviously the error is indepent of the operation system.
Me too. :-(
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?
@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
I see. So it's not Dropbox. Thanks!
On Sun, 12 May 2019 at 01:49, Johannes Kalliauer [email protected] 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 .
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
@sfo: How large is your libary? (filesize/entries)
Over 4000
Sent from Android phone
On Wed, 12 Jun 2019, 00:41 Johannes Kalliauer, [email protected] 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 .
@JoKalliauer here is a minimum working example:
% Encoding: UTF-8
@Article{,
}
@Comment{jabref-meta: databaseType:biblatex;}
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
Please check if you any save actions (library properties) or autosave enabled (preferences)
Please check if you any save actions (library properties) or autosave enabled (preferences)
Both save actions and autosave are disabled. The issue persists
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.
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.
Refs https://github.com/JabRef/jabref/issues/5085
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 :)
@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.
@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).
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
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
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.
@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.
Related:
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.
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
Note to self: We really need .bak
because of AtomicFileOutputStream
.
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.
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.
`
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?
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
JabRef 5.0.0-dev--2019-11-29----ea5e632e4 Linux 5.3.0-23-generic amd64 Java 13.0.1
Still getting it :-(