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

Saving creates new database file instead of overwriting the old one #2633

Open
TLCFEM opened this issue Mar 12, 2017 · 15 comments
Open

Saving creates new database file instead of overwriting the old one #2633

TLCFEM opened this issue Mar 12, 2017 · 15 comments

Comments

@TLCFEM
Copy link

@TLCFEM TLCFEM commented Mar 12, 2017

It seems that the new version 3.8.2 changes the saving manner. The old versions just overwrite the original file. I guess the new version rename the orginal file to the backup file and write a new database file.

This causes trouble for me (maybe also for others). I use hard links to point to the same database file in different folders so that the database can be updated automatically.

Currently the orginal file is either deleted or renamed. Hence the link is broken.

Will the developers consider to change it back to original saving manner?

@koppor
Copy link
Member

@koppor koppor commented Mar 13, 2017

Refs #2635

@koppor koppor added the os: linux label Mar 13, 2017
@TLCFEM
Copy link
Author

@TLCFEM TLCFEM commented Mar 13, 2017

I'd like to kindly comment that I am using Windows 7 so...

@koppor koppor removed the os: linux label Mar 13, 2017
@stefan-kolb stefan-kolb changed the title 3.8.2 SAVING ISSUES Saving creates new database file instead of overwriting the old one Mar 13, 2017
@stefan-kolb
Copy link
Member

@stefan-kolb stefan-kolb commented Sep 14, 2017

@JabRef/developers Is this still valid for 4.0? Will we change this?

@TLCFEM
Copy link
Author

@TLCFEM TLCFEM commented Sep 14, 2017

As far as I can tell, in 4.0 beta 3 the problem still exist..

@koppor
Copy link
Member

@koppor koppor commented Sep 14, 2017

@TLCFEM You say, that 3.8.1 worked correctly or some other earlier version?

@TLCFEM
Copy link
Author

@TLCFEM TLCFEM commented Sep 14, 2017

It has been a long time and I cannot remember exactly. So far I can tell that version 3.6 works properly so the modification was carried out somewhere between version 3.6 and 3.8.2. And I am sure that there is no fix since 3.8.2. I know little about Java so I cannot examine the codes and locate the problem. Sorry for little information provided.

@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Sep 15, 2017

So your final aim is to include one bib file in many tex documents without having to copy the file over and over again? For this, TeX actually provides a neat mechanism: you can put your bib file in a central folder (or register the current location within your TeX distribution), where every TeX document find it. See for example the following answer to a similar question.

@koppor
Copy link
Member

@koppor koppor commented Sep 18, 2017

Solution for a potential developer: Check our file mode when writing. It should truncate + append, not delete and recreate.

@fhoefling
Copy link

@fhoefling fhoefling commented Apr 21, 2020

It seems that the issue is back in version 5.0 on Linux.

I have a bib file, which has multiple hard links to other locations. Opening the file with JabRef, making a small change, and saving the file (Ctrl-S) breaks the hardlink. The inode count of the saved file is 1.

@fhoefling
Copy link

@fhoefling fhoefling commented Aug 5, 2020

The issue is still present in version 5.1, and it is really annoying. I'm using the same hard-link approach as @TLCFEM

@tobiasdiez Can you please reopen this unsolved issue? If this is not possible, I will file a new one.

@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Aug 5, 2020

I'm afraid that this is limitation of the current implementation that cannot be removed. Here is our strategy:

* In detail, the strategy is to:
* <ol>
* <li>Write to a temporary file (with .tmp suffix) in the same directory as the destination file.</li>
* <li>Create a backup (with .bak suffix) of the original file (if it exists) in the same directory.</li>
* <li>Move the temporary file to the correct place, overwriting any file that already exists at that location.</li>
* <li>Delete the backup file (if configured to do so).</li>
* </ol>
* If all goes well, no temporary or backup files will remain on disk after closing the stream.

We do not write directly to the existing file as this lead to many problems.

@fhoefling
Copy link

@fhoefling fhoefling commented Aug 5, 2020

@fhoefling
Copy link

@fhoefling fhoefling commented Aug 6, 2020

@Siedlerchr
Copy link
Contributor

@Siedlerchr Siedlerchr commented Aug 6, 2020

Just note that an Atomic move is only possible on the same file system, only in the same folder.

@tobiasdiez
Copy link
Member

@tobiasdiez tobiasdiez commented Aug 6, 2020

Thanks for your input.

We do not want to write to the file immediately as this may leave the file in an inconsistent state if something goes wrong during the writing process. So that's not an option.

So the only advantage of the two swaps is that the symlinks are still working, since we write to the original file? To be honest, that sounds like a lot of complication just for symlinks. Moreover, this needs to be extensively tested (especially with regard to file sharing services like Dropbox etc). I'm not saying this couldn't be implemented like that, just that it's very unlikely that the core team is doing. PRs are welcome.

Instead of symlinks, its might be easier to put the bib file into a central folder that is seen by tex. There are many ways to do this, see https://tex.stackexchange.com/questions/30494/how-to-make-latex-see-local-texmf-tree.

@koppor koppor reopened this Aug 6, 2020
@koppor koppor added this to Normal priority in Features & Enhancements via automation Aug 6, 2020
@koppor koppor moved this from Normal priority to Low priority in Features & Enhancements Aug 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Features & Enhancements
  
Low priority
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants