JabRef breaks hard links to .bib files

[sparusaurata]

I use JabRef version 5.2 on Linux Mint 20.1. When I open a .bib file and modify it with JabRef, its inode number is modified and the hard links are broken. An example:

$ ln these.bib Simulation\ βinf

$ ls -i these.bib
9440991 these.bib

$ ls -i Simulation\ βinf/these.bib
9440991 'Simulation βinf/these.bib'

# Open JabRef and modify these.bib

$ ls -li these.bib                
9437275 -rw-rw-r-- 1 remy remy 26060 mai    8 16:51 these.bib

$ ls -li Simulation\ βinf/these.bib      
9440991 -rw-rw-r-- 1 remy remy 26060 mai    8 16:38 'Simulation βinf/these.bib'

[Siedlerchr]

This is correct in so far that JabRef writes all content to a temporary file first and then replaces the existing file in an atomic move where possible.

[sparusaurata]

And would it be conceivable to do it some other way (naive question)? (In my case using hard links is necessary because I work in a git repo, and symbolic links would not be pushed correctly to remotes.)

[Siedlerchr]

This somehow refs https://github.com/JabRef/jabref/pull/6694 There is a lengthy discussion. I have been working on this saving already and I am experimenting if this works fine if I directly write to the bib file.

May I ask why you need a hard link? Why don't you edit the file directly in the repo?

[sparusaurata]

May I ask why you need a hard link? Why don't you edit the file directly in the repo?

The main .bib file, located in some root folder, is used by several projects (and associated git repos) located in subfolders. That's why I created a (hard) link to the main bibliography in each repo.

An easy workaround (that is sufficient for my projects) is to create copies instead of links, and to renew them from time to time. But in general it doesn't seem very satisfactory.

[ilippert]

I have been frustrated for years about this.

My workaround is now simplistic: I store my core library at a specific place X. And in the bibtex file I reference that file F with its complete path.

[sparusaurata]

My workaround is now simplistic: I store my core library at a specific place X. And in the bibtex file I reference that file F with its complete path.

But this wouldn't solve my git problem, would it? (See that comment.)

[glciampaglia]

+1 --- I just stumbled on this issue. Like @sparusaurata, I also keep my bib file in a central location and link to it within individual latex projects. Normally, I use a symbolic link, but this time I have created a hard link instead because I am using Overleaf's own git repository for syncing. So neither a symbolic link, nor using a full path (as suggested by @ilippert) would work.

I was excited about trying out this different setup because it would make it less painful to use JabRef with Overleaf projects, which now are the norm.

(Right now when you want to edit a bib file stored in an Overleaf project you need to download it from Overleaf, edit it with JabRef, and then reupload it.)

[koppor]

This is a hard one. We need to rethink of our writing. We were pointed to different implementation approaches at https://github.com/JabRef/jabref/pull/8750#issuecomment-1214455276.

@glciampaglia Does VisualStudio Code properly handle hard links?

[glciampaglia]

@koppor I am not sure since I am not a VSCode user myself. I am afraid I don't have technical skills to be very much of help here, but can only say that solving this issue would definitely make it possible to keep a centralized DB shared across multiple versioned projects, as @sparusaurata mentioned.

[koppor]

For implementation:

• [ ] Write tests by calling JabRef's functionality with different settings of file links on a unix file system. This could maybe ref https://github.com/JabRef/jabref/issues/110.