JabRef 3.3 spawns save.bib files

Help
1

I upgraded to JabRef 3.3 from JabRef 2.* about 2-3 weeks ago. Things were working fine until now. When I now try to save my databases it turns out that my /tmp directory (in Debian) has become 100% full (2 Gb?). In it are perhaps a hundred files of the form jabref3890608024893401806save.bib. The date of the files falls within the last 2-3 weeks.

When I use JabRef, I’m in the habit of saving frequently because in the past I sometimes loose data I just put in, and it is entirely possible the hundred saves are from the last few weeks. What is JabRef 3.3’s mechanism for disposing of dated backup files?

2

Do you get any errors in the JabRef log, like “Cannot delete temporary file”?

3

I didn’t follow up on my question because when I did $ rm
jabref*.save.bib, not only did I recover space in that partition, but
henceforth sames too the form jabref*.save (if I recall correctly).

But now you ask about the jabref log file. I never new jabref had a log
file. but in searching for it, I discovered my old problem had
returned. I have now about 60 backups in the form /tmp/jabref*.save.bib
of each of my seven .bib database files.

Please, where is this jabref.log file? I looked at the manual and did an
online search briefly, and nothing popped up.

4

With log file I mean Help -> Show error console output.

5

Understood. I look at the log. I assume new reports are appended to the
end. It starts with errors save exception: no space left on device. So I
look at the end of the file. There are a couple small problems that are
not relevant here, but just before them I get:

11:26:22.796 [Spin-1323] ERROR net.sf.jabref.exporter.SaveDatabaseAction - Problem saving file
net.sf.jabref.exporter.SaveException: rt
at net.sf.jabref.exporter.SaveDatabaseAction.saveDatabase(SaveDatabaseAction.java:246) ~[JabRef-3.3.jar:?]
at net.sf.jabref.exporter.SaveDatabaseAction.run(SaveDatabaseAction.java:171) [JabRef-3.3.jar:?]
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
at spin.Invocation.evaluate(Invocation.java:175) [JabRef-3.3.jar:?]
at spin.off.SpinOffEvaluator$1.run(SpinOffEvaluator.java:108) [JabRef-3.3.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]

I hope this is revealing.

Haines Brown