JabRef and Dropbox conflict: "Could not save, file locked by another JabRef instance"


Hello, I have been using JabRef for several years, but now I run into this annoying issue every time I try to save a bib entry. The error message is in the title of this topic. Interestingly, I notice that there is a file “mybibliography.bib.lock” generated when this occurs (mybibliography.bib is my bib database file). And if I delete it, I can then save the entry. Can anyone help me out here? It’s driving me crazy. Many thanks!

(Bernhard Kleine) #2

What comes to mind is that you could restrict the Jabref to have not more than one instance: you could open Remote operations https://help.jabref.org/en/Remote. Than there would be running a single instance of Jabref and the problem could be avoided. I use this for JabFox import (Port 6050). BTW I could not find the .lock file, where is it in relation to the library?

(Christoph) #3

Do you have Autosave enabled?


Hi Bernhard, thanks for looking into the problem. Should I check or uncheck the remote operation option? I did both, but the lock file is generated anyway and so I still couldn’t save. The lock file is generated under the same folder as the bib file, and has the same name.


Hi Christoph, thanks for the help. I did have it enabled (by default). When I disabled it, the problem still persists.

(Bernhard Kleine) #6

I have Jabref 4.0 on Win7. I cannot see any lock file in the folder with the bib-files. I made sure that hidden files are shown. You didnot tell us which version of jabref and which system you have.


Hi Bernhard, sorry about that. I also have Jabref 4.0, but the problem started with the previous version as well, both were run in Windows 10. I don’t know what happened, and I didn’t change any configurations (that I am aware of) until what you and Christoph suggested me do. I think the fact you don’t have the lock file is precisely the reason why you don’t have the problem. Thanks.

(Tobias Diez) #8

The lock file (.lock) is always created when you save a file but should normally be deleted directly afterwards. Its only purpose is to ensure that JabRef does not write to the same file simultaneously (e.g. if you press “Save” twice).

Can you reproduce that the lock files remains after a save? Everytime? Does it only happens for a particular file/in a particular folder?


Hi Tobias, yes, the lock file is generated every time I try to save and because I couldn’t save it then stays there. In fact, there is another local file for mybibliography.bib.sav. And these happen for other files/folders/computers that I use as well. Thank you.

(Tobias Diez) #10

Ok, lets try to slowly analyze the problem. The normal process looks like this:

  1. Create lock file
  2. Save database (creating a backup file)
  3. Delete lock file

The lock file should be deleted even in case of an error.
Can you please have a look what is happening in your case. Probably the best is if you open JabRef on one side of the monitor and on the other side have the explorer in the folder of your bib file. Please first delete a possible left lock file. Then make a small change in Jabref and save, while looking at the explorer and report what happens there. Do you get an error message in JabRef (Help > Error console)? Thanks for your assistance!


Following your instructions, here is what happened.

  1. I opened JabRef and made a small change of some entry.
  2. I l clicked the save button and saved successfully, and meanwhile the lock file was generated and stayed here after.
  3. Then I made another change, but was unable to save.
  4. I deleted the lock file and then saved successfully.

Then I did another experiment and found something interesting. The bib file is in a Dropbox folder, so I thought maybe the Dropbox was trying to sync the lock file while Jabref was trying to delete it and wasn’t able to do so as as a result. So I moved the bib file outside the Dropbox, and guess what? The problem disappears. Not only that. There was no lock file generated, unlike before. This is rather odd because the bib file has always been in the same Dropbox folder and there had been no problem until a while ago. I would also like to keep putting it in the Dropbox folder so I can access it anywhere I want. Any ideas?


(Tobias Diez) #12

Good, so its a problem with the interaction of JabRef and Dropbox. As you suggest, Dropbox probably tries to upload the lock file in the same moment when JabRef actually wants to delete it again.

You might try to ignore the lock file as outlined here: https://superuser.com/questions/469776/how-to-exclude-files-not-folders-from-dropbox-sync. If this does not work, you can put the bib file somewhere else (and open this file with JabRef) and create a hard link in your dropbox folder.


Thanks for the suggestion, Tobias. I just tried the first approach. It didn’t work. The thing is, whenever I try to save, there will be an auto saved file and a lock file associated with it (so there are two lock files in total). Also, even if it works, the file will not be synced, right? I still want to have it synced. And how does the hard link work exactly? Will the file be synced in that case? Thanks!

(Bernhard Kleine) #14

I am glad that I did not miss anything on my harddisk, since I could not find the lock file. This is some special situation with respect to dropbox and jabref. Please make sure to change the title of the thread accordingly!

(Tobias Diez) #15

@Pittance I meant that you should try to ignore the lock file not your main bib file. So Dropbox would still sync the bib file but would ignore the lock and so hopefully JabRef could remove the lock.

Sadly my idea to use hard links does not work either since Dropbox breaks those links. Maybe you could pause Dropbox while actively working with JabRef and when you are finished, resume it? Sorry but I’m running out of ideas…personally, I use git to sync my bib files but there is an inherit overhead in this method (but also additional benefits like version history).


Ah, I misunderstood. YES, it works! Now life is back to normal. Thanks Tobias! Hopefully JabRef or Dropbox can take care of this issue in future.