I raised this question quite some time ago but received no responses.
I’m running JabRef 3.3 (stuck there because of the oft-discussed groups problem) and have seven databases. When I explicitly back a database up (C-s), the database is saved as a /tmp/jabref*.tmp file. When I back the database up again, the old .tmp file is overwritten by the new one.
However, exactly every five minutes three of my seven databases are automatically backed up to a file named /tmp/jabref*.save.bib. This occurs even though no operations are being done with JabRef such as a Save command. Because there is no automatic deletion of these files each time there is a new save, they accumulate to the point it fills my 20 Gb /tmp directory.
It seems the three databases are configured differently, but I find no difference. In the Preferences for all seven I have checked Backup old file while saving. I don’t know of any JabRef automatic backup system that runs every five minutes. I checked /var/log/chron.log and there is no cron job doing it. I could write a script to delete these .save.bib
files automatically, but I’d rather address the source of the problem.
I see that I have autosave set to 5 min on all seven databases. So my question reduces to this: why are only three of seven databases? Then shouldn’t autosave overwrite the previous save instead of adding to it?
If I remember correctly there were quite a few problems related to the autosave procedure in the old versions and this is why it was more or less completely rewritten recently.
So I suggest the easiest solution is to upgrade to a newer version (with the workaround I outlined in the group issue, this shouldn’t be a problem - but please make a backup).
Tobias, I hesitated to implement your suggestion for a work around because when I initially upgraded to a JabRef > 3.4 it altered my database files and recovery was not complete. Are you saying that I can a) make a backup of the database files, b) run JabRef > 3.4 and open the databases, c) change to keyword groups with field=group. Not running a newer JabRef I could not see just what this means and try it out. But does the work-around simply mean going down the three or four levels in the the group tree hierarchy and edit each group by changing it to keyword group (whatever that is)? Then use of the group tree would remain the same as before?
Create a backup of your .bib file (so in case something doesn’t work, you don’t loose your data)
Open the bib file in JabRef 3.3 (not newer!)
Change all static groups that have duplicate names to a keyword group with field = groups and search text = something unique. You will be asked if you want to assign the previously assigned entries to the new group; answer with yes.
Close Jabref 3.3
Install newer version (a beta of 4.0 will be out in a few hours) and open the bib file in it. Your groups should still work and no entry should be assigned falsely to two groups.
I’ll do as you suggest, but first two little questions. You say to change all static groups for which there are duplicate names to a keyword group. Since my group hierarchies are very large and complex, is there any reason I should not simply change all groups below the top level to keyword groups? Is there any reason why all groups below the top level should not be keyword groups? Second, you suggest setting “search text” to “something unique”. Not sure what this means. What is the function of “search text”? Is it to search for a term in the group hierarchy rather than the database records? If so, I’ve not yet encountered and can’t see why I would use it. Does the uniqueness of “something unique” refer to the entire group hierarchy or only items below a top level? If for a subgroup named, for example, “green”, I set the unique name to “green-bis”, then does a search for “green” no longer work?
In newer JabRef versions a static group with name test is a shortcut for a keyword group with field = groups, name = test and searchtext = test. So there is definitely no harm in converting every static group to a keyword group.
The search text is used to identify the entries that assigned to the group. For example, field = groups and searchtext = test matches all entries that have test in the groups field. So if you have two keyword groups with the same searchtext then they also match the same entries. Take the groups tree
A
C
B
C
as an example. For the first C group you want a search text that expresses the fact that this group is a subgroup of A, so for example searchtext = A > C. Similarly, for the second C group, you say B > C. But you can choose these search texts completely freely, so for example searchtext = my very first C and searchtext = second C also work; as long as they are unique.
I followed your recommendations and it is working on JabRef 3.3. So far so good. Thank you.
So when I finish doing this for all group names, I suppose even highest level in the hierarchy, then (after a backup) I can open the databases with JabRef > 3.4 and I’ll be able to use the groups hierarchy as I now do except that the group assignment information will no longer be held in the .bib files.
Can’t carry this out now because the process will take quite some time.