When saving: The libary has been modified by another program

[JoKalliauer]

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 )

1. open .bib-file
2. press "ctrl" & "s"
3. Repeat step 2 till Bug appears.
4. The message "The library has been modified by another program" appears
5. 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 ```

[tobiasdiez]

@bernhard-kleine @reox could you please try out the latest dev version from http://builds.jabref.org/master/. I made some improvements on the change detection code. This might fix at least some aspects of this bug.

If the bug still occurs, it would be imensively helpful if you could provide the following for the items that are claimed to have changed:

• Bibtex code before (copy before you press "Review changes") and wheather this coincides with what is in the bib file
• Screenshot of the claimed changes in the Change dialog
• Bibtex code after you accept code
• Bibtex code in the file after you save (with the accepted changes).

Thanks!

[reox]

Nice! So far, I did not saw the message popping up!

[tobiasdiez]

That's extra strange as my changes are not yet uploaded :-) The build takes about 0.5h...

[wujastyk]

JabRef 5.0-beta.19--2019-12-20--9b0dd5d Linux 5.3.0-24-generic amd64 Java 13.0.1

In some very superficial tests, I'm no longer getting the "library modified" message. These superficial tests (small mod to a single record, then save) did produce the erroneous behaviour before today's version. So it's looking promising! Thank you @tobiasdiez

[Siedlerchr]

@tobiasdiez Looks also good from my side. When testing and debugging #5688 I noticed that there a actually three threads spawned for one change:

1. Open bib file in JabRef
2. Open bib file in Notepad++
3. Modfiy one entry
4. scanForchanges is called three times

Don't know if this is related to always reformat on save option or so (my preferences dialog is currently broken)

[bernhard-kleine]

Unfortunately, I cannot confirm that the behavior is gone. I typed hardcopy into the comment field and the message appeared. The console window does not show any error message, the event log is empty.

JabRef 5.0-beta.19--2019-12-20--9b0dd5d Windows 7 6.1 amd64 Java 13.0.1

[tobiasdiez]

@bernhard-kleine Can you please provide the information outlined at https://github.com/JabRef/jabref/issues/4877#issuecomment-567914548

[wujastyk]

JabRef 5.0-beta.20--2019-12-20--c19feb1 Linux 5.3.0-24-generic amd64 Java 13.0.1

Ah, schade. I now have the bad behaviour too. But after I took the screenshot, I couldn't reproduce it, so I haven't been able to do the before/after tests you ask for.

I have noticed a severe slowdown in keystroke reading.

[bernhard-kleine]

Can you always replicate the bug with your database? no With the minimal example above? no On which OS? Linux or Windows? Or both? working only in Windows7 Does it matter where the database is saved? AFAIK no Does it also occur if you choose "Save as" and write the file to somewhere else? no If you choose "Save as" but overwrite the original file? no Are only entries concerned, or also other data in the library? ( Try to add Strings, Preamble: no and change a few settings under Library properties. Save, close JabRef, open again and experiment now with saving) yes

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).

Clicking metadata does not open anything

[reox]

That's extra strange as my changes are not yet uploaded :-) The build takes about 0.5h...

LOL okay, maybe something else was patched in the meantime? I'll test with the latest version now too...

btw: are the debian packages disabled for the snapshots?

edit: with the latest snapshot, the messages do not appear for me. So it seems like it is fixed at least for me

JabRef 5.0-beta.33--2019-12-24--dfe2d2d
Linux 5.3.0-3-amd64 amd64 
Java 13.0.1

[wujastyk]

JabRef 5.0-beta.89--2020-01-02--1180dfc Linux 5.3.0-24-generic amd64 Java 13.0.1

I am unable to reproduce this error in today's release. My testing is on a database of 4000 entries. The tests I've done were pretty minimal, I'm afraid. Just editing a couple of fields and saving.

However, today's release is unusable because editing is so slow. One waits seconds for a keystroke to be obeyed. Moving around menus, however, is fine.

--- added a day later:

JabRef 5.0-beta.94--2020-01-03--f11949f Linux 5.3.0-24-generic amd64 Java 13.0.1

Nope, I saw the "library has been modified" message again this morning. Data entry keystrokes still slow, but not when editing the raw biblatex entry. I think it may have to do with updating the preview display. When the preview is not on screen, keystrokes are faster. Possibly?

[JoKalliauer]

JabRef 5.0-beta.89--2020-01-02--1180dfc Linux 4.15.0-74-generic amd64 Java 13.0.1

Answering on https://github.com/JabRef/jabref/issues/4877#issuecomment-567914548

If the bug still occurs, it would be imensively helpful if you could provide the following for the items that are claimed to have changed:

Bibtex code before (copy before you press "Review changes") and wheather this coincides with what is in the bib file

[BibBefore.bib.txt](deleted File)

Screenshot of the claimed changes in the Change dialog

Bibtex code after you accept code

[BibAccepted.bib.txt](deleted File)

Bibtex code in the file after you save (with the accepted changes).

[BibSaved.bib.txt](deleted File)

PS1 the bib file is kept unchanged PS2 I did neither add or delete a rank in today's session (I did not change any rank within the last weeks/months, I do not use this field any more)

[matthiasgeiger]

This sounds really weird...

Can you please check whether there is a .bak or .sav file in the same folder as your .bib file?

Maybe these file is still containing same old rank information?

[JoKalliauer]

The .bib.bak-file and the .bib.sav-file (only exists if JabRef is opened) are currently identical. Before I checked and .bib.bak had an whole entry "hellmich2019ingenieurmechanik" less, but if I remember correctly the *.bib.sav-file was identical with the .bib-file.

I cannot reproduce the bug (it only occurs sometimes), that makes it difficult to report. In the earlier session it occurred three times after each other (whithout changes after the first save) then I closed JabRef. In the current session I tried three times and I wasn't able to reproduce the bug.

The suggested changes in the original bug, were different from the suggested changes now.

If the function makes problems, why not add a option in settings to disable the feature/bug?

[Siedlerchr]

Could you please check the settings, if you have "Reformat the bib file on save" enabled?

[wujastyk]

JabRef 5.0-beta.335--2020-01-09--93f47c9 Linux 5.3.0-24-generic amd64 Java 13.0.1

Still having the problem.

[image: Screenshot from 2020-01-09 12-12-24.png]

BibTeX file before pressing "dismiss" and after pressing "dismiss" are identical:

[image: Screenshot from 2020-01-09 12-13-27.png] Bibtex bib file appended. biblio4-utf8.bib.txt

reformat is off:

[image: image.png]

My settings file, jabref.xml is attached.

jabref.xml.txt

[JoKalliauer]

Could you please check the settings, if you have "Reformat the bib file on save" enabled?

It is disabled.

[JoKalliauer]

I now enabled it and it suggests many changes such as "&" to "\&" and several linebreak-changes.

[JoKalliauer]

I disabled it again (still in the same session), not it only reports the linebreaks (I also changed it form "\r\n" to "\n") but not the & any more. But accepting leaded to "Uncaught exeption occured in Tread"

[wujastyk]

JabRef 5.0-beta.336--2020-01-10--5f2ffb2 Linux 5.3.0-24-generic amd64 Java 13.0.1

The keystroke slowdown I reported above has stopped being a problem in today's release.

[tobiasdiez]

The key collision exception should be fixed now. Moreover, I added a more detailed view of the (claimed) metadata changes. So @wujastyk if you get the message again, please make a screenshot of the changes so than we can narrow down the real trigger. Thanks.

This leaves the following two problems:

• [ ] Claimed changes in ranking. I guess this goes back to how special fields are synced with the keyword field (in the screenshot rank4 is in ranking as well as in keywords)
• [ ] Claimed changes in special characters like & and new lines. I remember that there is a special encoding/decoding mechanism in place. @JabRef/developers do you know where exactly this is applied?

[bernhard-kleine]

I have in a library the "General and Comparative Endocrinology" change to the abbreviated form. In order to get Gen. Comp. Endocrinol. I pressed the button on the right side of "Journal" 3times. The error "library has been changed... appeared. working with the release of yesterday: JabRef 5.0-beta.336--2020-01-10--5f2ffb2; Windows 7 6.1 amd64 ; Java 13.0.1.

[bernhard-kleine]

The error works on a library with one single entry of Gen.Comp.Endo. Error message in the start Screen says.

ERROR BackupManager Error while saving to fileK:\BuchprojektSpringer\VierteAuflage\Literatur\test6.bib.sav java.nio.file.NoSuchFileException: K:\BuchprojektSpringer\VierteAuflage\Literatur\test6.bib.sav.tmp -> K:\BuchprojektSp ringer\VierteAuflage\Literatur\test6.bib.sav 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) at org.jabref/org.jabref.logic.autosaveandbackup.BackupManager.performBackup(Unknown Source) at java.base/java.util.Optional.ifPresent(Unknown Source) at org.jabref/org.jabref.logic.autosaveandbackup.BackupManager.lambda$new$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)

The offending entry:

@Article{VDM+19,
  author          = {Valle, Shelley and Das, Chandrima and Meddle, Simone L. and Deviche, Pierre},
  year            = {2019},
  title           = {The effect of food restriction on the regulation of gonadotropin-releasing hormone in male house finches (Haemorhous mexicanus).},
  abstract        = {Seasonal activation of the vertebrate hypothalamic-pituitary-gonadal (HPG) axis and gonadal development is initiated by gonadotropin-releasing hormone-I (GnRH) release from the hypothalamus. In photoperiodic species, the consistent annual change in photoperiod is the primary environmental signal affecting GnRH cell activity, including changes in the synthesis and secretion of this neuropeptide. Non-photoperiodic environmental cues such as energy availability also influence HPG axis activity, but the mechanisms mediating this influence, in particular on the GnRH system, are unclear. Understanding how the neuroendocrine system integrates environmental information is critical in determining the plasticity and adaptability of physiological responses to changing environments. The primary objective of this study was to investigate GnRH-mediated changes in HPG axis activity and gonadal development in response to energy availability in a wild bird. We hypothesized that negative energy balance inhibits HPG axis activity by affecting GnRH secretion. Moderate food restriction for several weeks in male house finches, Haemorhous mexicanus, decreased body condition and inhibited photoinduced testicular growth compared to birds fed ad libitum. Food restriction did not affect plasma luteinizing hormone (LH; a correlate of GnRH release) or plasma testosterone, but it enhanced the plasma LH response to an injection of the glutamatergic agonist, N-methyl-D-aspartate (NMDA). Thus, food restriction may decrease photoinduced HPG axis activation by acting centrally, in particular by attenuating the release of accumulated GnRH stores.},
  doi             = {10.1016/j.ygcen.2019.05.021},
  issn            = {1095-6840},
  month           = oct,
  pages           = {113196},
  pubstate        = {ppublish},
  volume          = {282},
  citation-subset = {IM},
  country         = {United States},
  issn-linking    = {0016-6480},
  journal         = {General and Comparative Endocrinology},
  keywords        = {Food restriction; Gonadotropin-releasing hormone; Luteinizing hormone; Passerine; Seasonal breeding; Testosterone},
  nlm-id          = {0370735},
  owner           = {bk},
  pii             = {S0016-6480(18)30705-6},
  pmid            = {31163182},
  pubmodel        = {Print-Electronic},
  revised         = {2019-11-20},
  timestamp       = {2020.01.11},
}

[tobiasdiez]

@bernhard-kleine Thanks for the feedback. However, the analysis of the bug showed so far that not the data in the library (i.e the entries) itself is the origin of the problem but some post/preprocessing done during load/save. To track these down we need information of the claimed changes, that is, screenshots of the dialog that appears after clicking the "review changes" button. Could you please also provide these information. Thanks!

[JoKalliauer]

JabRef 5.0-beta.334--2020-01-08--cafdb01 Linux 4.15.0-74-generic amd64 Java 13.0.1

New entry with BIB-export from https://pubs.acs.org/doi/10.1021/ja0654229 inserted into source-code-editor of JabRef

@Article{maye2006a,
author = {Maye, Mathew M. and Nykypanchuk, Dmytro and van der Lelie, Daniel and Gang, Oleg},
title = {A Simple Method for Kinetic Control of DNA-Induced Nanoparticle Assembly},
journal = {Journal of the American Chemical Society},
volume = {128},
number = {43},
pages = {14020-14021},
year = {2006},
doi = {10.1021/ja0654229},
    note ={PMID: 17061872},

URL = { 
        https://doi.org/10.1021/ja0654229

},
eprint = { 
        https://doi.org/10.1021/ja0654229

},
  owner     = {jkalliau},
  timestamp = {2020.01.13},
}

merged/completed entries with DOI-Data

added the pdf over GUI (Allgemein (german for "General")->File-->...)

pressed "Control" & "s" (Changeswarning)

clicked on check Changes

clicked on accept

pressed "Control" & "s" again (Changeswarning again)

clicked on check Changes

clicked on accept again

pressed "Control" & "s" again (Changeswarning again)

.bib and .bib.sav both the same (.bak dissabled)

@Article{maye2006a,
  author    = {Maye, Mathew M. and Nykypanchuk, Dmytro and van der Lelie, Daniel and Gang, Oleg},
  journal   = {Journal of the American Chemical Society},
  title     = {A Simple Method for Kinetic Control of {DNA}-Induced Nanoparticle Assembly},
  year      = {2006},
  month     = {nov},
  note      = {PMID: 17061872},
  number    = {43},
  pages     = {14020--14021},
  volume    = {128},
  doi       = {10.1021/ja0654229},
  eprint    = {https://doi.org/10.1021/ja0654229},
  file      = {:PhDJK/Literature/Rivetti_Walker_Bustamante_1998_JMolBiol_280.pdf:PDF},
  owner     = {jkalliau},
  publisher = {American Chemical Society ({ACS})},
  timestamp = {2020.01.13},
  url       = {https://doi.org/10.1021/ja0654229},
}

vimdiff did not report any changes between .bib and .bib.sav

Now I changed the option to the right choice (sorry forgot screenshot, but the same changes as before)

pressed "Control" & "s" again (now no warning?!)

.bib and .bib.sav both the same (seems to be identical as before)

@Article{maye2006a,
  author    = {Maye, Mathew M. and Nykypanchuk, Dmytro and van der Lelie, Daniel and Gang, Oleg},
  journal   = {Journal of the American Chemical Society},
  title     = {A Simple Method for Kinetic Control of {DNA}-Induced Nanoparticle Assembly},
  year      = {2006},
  month     = {nov},
  note      = {PMID: 17061872},
  number    = {43},
  pages     = {14020--14021},
  volume    = {128},
  doi       = {10.1021/ja0654229},
  eprint    = {https://doi.org/10.1021/ja0654229},
  file      = {:PhDJK/Literature/Rivetti_Walker_Bustamante_1998_JMolBiol_280.pdf:PDF},
  owner     = {jkalliau},
  publisher = {American Chemical Society ({ACS})},
  timestamp = {2020.01.13},
  url       = {https://doi.org/10.1021/ja0654229},
}

vimdiff reports again no changes between .bib and .bib.sav

Here are my settings:

closed JabRef

[tobiasdiez]

Thanks a lot, @JoKalliauer. I think I know where this bug comes from now.

• When JabRef saves the database, it does a bit of elementary cleanup (like removing empty spaces or normalizing new lines)
• Thus, the saved database is slightly different to the current in-memory database.
• The change detection algorithm complains about these changes.

Proposed fix: the pre-save cleanup should be applied to the in-memory entries as well.

[bernhard-kleine]

@tobiasdiez

Sorry, to be late: This is what I did: I opened my standard library and a second, empty library. I copied an entry of Gen. Comp. Endocrinol. from the standard library to the empty one. I changed to the abbreviation of the journal several times in the not yet saved library without any error message. Then I saved the library and did the same to the journal title. Immediately the error message appeared. The review changes shows only the following:

Hope that helps.

[bernhard-kleine]

with JabRef 5.0-beta.342--2020-01-15--58709e7 the review changes dialog is now:

[bernhard-kleine]

@igorsteinmacher: please change your email settings away from bouncing!!!!

[igorsteinmacher]

Sorry about that @bernhard-kleine, all.

[wujastyk]

JabRef 5.0-beta.342--2020-01-15--58709e7 Linux 5.3.0-24-generic amd64 Java 13.0.2

SSD drive; Dropbox active.

I tried the MWE from @igorsteinmacher and got the error! Amazing, really. A single, empty, @article{} entry.

Here, @tobiasdiez , is the result of "Review changes":

I saved a copy of the original bib file and the one after accepting all changes, and they were identical.

Then, after making edits and saving again, the error did not repeat, even after half a dozen edit/save cycles.

[tobiasdiez]

Thanks everybody for your feedback.

This bug should be finally 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.

[wujastyk]

JabRef 5.0-beta.352--2020-01-18--49e8ee2 Linux 5.3.0-26-generic amd64 Java 13.0.2

So far so good! Thank you!

[AEgit]

JabRef 5.0-beta.354--2020-01-18--2612e22 Windows 10 10.0 amd64 Java 13.0.2

As far as I can tell, this bug has been fixed. Note, however, that JabRef will display the "Saving library..." message multiple times (and probably also carry out the save action multiple times?) if you press CTRL + S multiple times consecutively. Is this behaviour intended? Basically, if a user is impatient and tries to save the database multiple times, in a short period of time, JabRef will proceed doing so (or at least displays the respective actions) multiple times. Shouldn't JabRef just stop after the first time, let's say if the user triggers the "Save" action multiple times within 5 sec or so? I mean, technically it is correct, what JabRef is doing, but shouldn't it get around such user behaviour (known as "DAU" behaviour in German).

[bernhard-kleine]

JabRef 5.0-beta.357--2020-01-18--6319d05 Windows 7 6.1 amd64 Java 13.0.2

Unfortunately I can not confirm, that the error message has been erased completely.

1. the example file, copying one entry of Gen. Comp. Endocrinol. into a fresh library, saving the library and changing the journal to the abbreviated form and back, does no longer raise the message.

2. saving of my standard library, however, raises the error as before. This library has long been fixed and saved. I donot understand why this error still exists. The screenshot (composed of two separate items) shows the review changes dialog. I could not see a single difference between the two versions. I could provide the library via my dropbox, but I need an email address. Mine is bernhard.kleine(at)gmx.net.

[tobiasdiez]

There is a difference in the keywords field (escaped vs unescaped ampersand).

[bernhard-kleine]

This difference is caused by Jabref, not by myself. The file on disk has the presumably correct escaped version, the one in memory not. Please explain this to me. This morning no error arises. I think this is very strange.

This is complaining of a very level. At the moment I am very content with the actual dev version.

[AEgit]

Have you tried to save the version that the new JabRef version provides at least once? If not, the following issue might be related:

https://github.com/JabRef/jabref/issues/5734#issuecomment-575885891

Note, that when I first open a JabRef database that has been created by an older version (either 3.8.2 or an older 5.0 version) it is displayed as having been subjected to changes (despite no user interaction). As far as I understand JabRef makes a few changes to these databases, the first time they are loaded. If you save those changes (by saving the database itself), the database should not longer be marked as having been subjected to changes. Otherwise, every time you open these databases (stored in an older format) will always show up as having been subjected to changes.

[bernhard-kleine]

@AEgit: I have been opening and saving the library daily for the sake of testing the bug. In the past, the review changes dialog has only been showing "metadata have changed". This time with the comparison between file on disk and that in jabref was totally new. However, I can not reproduce the bug this morning since the error message does not occur any further.

[AEgit]

Hmmm, a strange behaviour, indeed.

[JoKalliauer]

As said by @tobiasdiez in https://github.com/JabRef/jabref/issues/4877#issuecomment-576049547 I have changes between (escaped vs unescaped ampersand)

Differently to @bernhard-kleine I only use unescape ampersand in the file, otherwise afaik the url won't work, however I also have on the left (in JabRef) side the unescaped and on the right side (on disk) the escape version.

This bug does occur even without saving. (?!)

[reox]

With the recent version

JabRef 5.0-beta.357--2020-01-18--6319d05
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 13.0.2

I now get this error:

I changed the author's name from W. Roux to Roux, Wilhelm and had autosave enabled. It looks like that the changes are somehow popping up while typing. I have auto-saving enabled.

edit: same behavior with:

JabRef 5.0-beta.360--2020-01-21--7ddfd9f
Linux 3.10.0-1062.1.1.el7.centos.plus.x86_64 amd64 
Java 13.0.2

[JoKalliauer]

JabRef 5.0-beta.357--2020-01-18--6319d05 Linux 4.15.0-76-generic amd64 Java 13.0.2

I added

@Article{doi:10.1080/15376494.2019.1647317, author = {Patricia Kuttke and Aleš Kurfürst and Stefan Scheiner and Christian Hellmich}, title = {Sequential 1D/2D Finite Element analyses of tramway rails under bending and restrained torsion, based on the principle of virtual power}, journal = {Mechanics of Advanced Materials and Structures}, volume = {0}, number = {0}, pages = {1-23}, year = {2019}, publisher = {Taylor & Francis}, doi = {10.1080/15376494.2019.1647317},

URL = { https://doi.org/10.1080/15376494.2019.1647317

}, eprintx = { https://doi.org/10.1080/15376494.2019.1647317

}, owner = {jkalliau}, timestamp = {2020.01.23}, }

I click on "Dissmiss", but however I get:

@Article{doi:10.1080/15376494.2019.1647317, author = {Patricia Kuttke and Aleš Kurfürst and Stefan Scheiner and Christian Hellmich}, journal = {Mechanics of Advanced Materials and Structures}, title = {Sequential 1D/2D Finite Element analyses of tramway rails under bending and restrained torsion, based on the principle of virtual power}, year = {2019}, number = {0}, pages = {1-23}, volume = {0}, doi = {10.1080/15376494.2019.1647317}, eprintx = {https://doi.org/10.1080/15376494.2019.1647317}, owner = {jkalliau}, publisher = {Taylor \& Francis}, timestamp = {2020.01.23}, url = {https://doi.org/10.1080/15376494.2019.1647317}, }

I think escape vs. unescaped ampersand should only be changed when "Cleanup entries", but not by default.

[bernhard-kleine]

This problem with ampersand is obviously a cleaning up issue. In my opinion, there shoould be another ticker for ampersands since this has only accidentially to do with the original problem. If you save the library, close it and reopen it, the error is gone. Waiting for some time and then saving again does not always show the error. Furthermore there is not any apparent java error since the log trace in the separate command window remains empty, while with original error you got a java-error (missing source or the like). These are the reasons while a propose another ticket.

[tobiasdiez]

I've located the problematic piece in the code and will try to provide a fix this weekend. Stay tuned.

[tobiasdiez]

The ampersand problem should be fixed now. In the hope that this finally fixes this issue, I'll close this one again.

If there should be further issues that are somehow related to this one here, please open a new issue.

[wujastyk]

JabRef 5.0-beta.406--2020-02-05--6fda10a Linux 5.3.0-28-generic amd64 Java 13.0.2

6 Feb: I'm still getting this "library has been modified by another program", even when I make no changes at all to the database, and just click on the "save library" icon.

This issue seems to be routine on one of my laptops, a Thinkpad 560, but now never happens on the other one, Thinkpad 580. Both machines are running identical Linux Mint versions, both are updated daily, both have plenty of space on their SSD drives (though the 560 has less space, but still many gigabytes). Both access the biblatex library in a folder that's mirrored by Dropbox.

[AEgit]

That is really weird. If they use the same operating system (same patch level), the same version of JabRef, and the same JabRef database, you would expect them to behave the same way. Hardware should not really matter.

To make sure things are exactly the same. Could you export your JabRef preferences (Options -> Preferences -> Export preferences) to check, whether they are exactly the same? Maybe check also the library properties (Library -> Library properties): Are they exactly the same?

[Siedlerchr]

I recently read about that java uses inotify on Linux to check for directory changes and that under certain circumstances it could not work properly. As you are on Linux, I think it really has to do with it.
https://blog.arkey.fr/2019/09/13/watchservice-and-bind-mount/

[wujastyk]

Okay, but my bib file is not on a network drive. All my laptops have the bib file locally. They're being synched by Dropbox, but they're definitely on the local disk.