Saving creates new database file instead of overwriting the old one

[TLCFEM]

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]

Refs #2635

[TLCFEM]

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

[stefan-kolb]

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

[TLCFEM]

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

[koppor]

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

[TLCFEM]

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]

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]

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

[fhoefling]

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]

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]

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

jabref/src/main/java/org/jabref/logic/exporter/AtomicFileOutputStream.java

Lines 25 to 32 in 9f96958

	* 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]

Thanks for the very quick reply and the link to the strategy. What is the purpose of the temporary file? What would be bad with this approach: 1) create a backup of the original file 2) write directly to the orginal file 3) remove the backup If anything goes wrong during 1), the backup is deleted. If an error occurs during 2), there is the backup. I see that moving the temporary is faster than writing directly to the original. (By the way, what kind of file sizes are we talking about?) This may matter for slow and unreliable network shares. For local files it seems irrelevant. Suggestion: use the "atomic" file output for remote files, but the direct one for local files. Would this be possible?

[fhoefling]

@tobiasdiez I have a suggestion for an improved strategy for atomic file output. The only requirement is a swap operation between two files, which can be implemented as a sequence of moves via a temporary. If one accepts this swap as being atomic, either performance can be improved or hard-links can be preserved. An atomic swap is actually available in the Linux kernel: https://stackoverflow.com/questions/27862057/atomically-swap-contents-of-two-files-on-linux First, elaborating on the existing strategy, one of the two file writes can be saved. This is suitable for remote files: 1) write new data to backup file (.bak) 2) swap original file and backup So we need only a single write (no copy of the original to the backup), and it leaves a proper backup of the original. If the swap fails, then either the original or the new version exists. Second, hard-links are preserved with the following modification, which requires two writes/copies as the existing implementation does: 1) create backup of original file by copy (.bak) 2) swap backup and original (.bib <-> .bak) 3) write directly to the backup (.bak) 4) swap backup and original again (.bib <-> .bak) Thereby, the original file is modified in place and, again, it leaves a proper backup. Implementation of the swap operation as three atomic moves: a) move backup to temporary (.bak -> .tmp) b) move original to backup (.bib -> .bak) c) move temporary to original (.tmp -> .bib) If the move in (b) fails (and .bib is destroyed), the new version is available in .tmp, which can then be copied(!) to the original place (.bib).

[Siedlerchr]

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

[tobiasdiez]

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.

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!