Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JabRef breaks hard links to .bib files #7718

Open
sparusaurata opened this issue May 8, 2021 · 9 comments
Open

JabRef breaks hard links to .bib files #7718

sparusaurata opened this issue May 8, 2021 · 9 comments
Assignees
Labels
bug Confirmed bugs or reports that are very likely to be bugs export / save
Projects

Comments

@sparusaurata
Copy link

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

This somehow refs #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
Copy link
Author

sparusaurata commented May 8, 2021

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
Copy link

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
Copy link
Author

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.)

@koppor koppor mentioned this issue Jun 14, 2022
14 tasks
@glciampaglia
Copy link

+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.)

@ThiloteE ThiloteE added bug Confirmed bugs or reports that are very likely to be bugs export / save shared-database labels Jul 21, 2022
@ThiloteE ThiloteE added this to Normal priority in Bugs via automation Jul 21, 2022
@koppor
Copy link
Member

koppor commented Dec 16, 2022

This is a hard one. We need to rethink of our writing. We were pointed to different implementation approaches at #8750 (comment).

@glciampaglia Does VisualStudio Code properly handle hard links?

@glciampaglia
Copy link

glciampaglia commented Jan 20, 2023

@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 koppor self-assigned this Mar 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs export / save
Projects
Status: Normal priority
Bugs
  
Normal priority
Development

No branches or pull requests

6 participants