JabRef 3.3 spawns save.bib files

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?

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

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.

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

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