More conservative write#8750
Conversation
|
Still does not fix one of the root issues that there is no Filelock and that this method can be executed in parallel |
This reverts commit 048729b.
There was a problem hiding this comment.
I would suggest to take some inspiration by established libraries like https://github.com/npm/write-file-atomic or https://github.com/typicode/steno that implement similar secure writes, if you haven't done so. In particular, adding the pid and threadid, and invocation counter to the temporary file name looks like a good idea. Also having a thread lock-by-file is a good design choice in my opinion.
|
|
||
| private void replaceOriginalFileByWrittenFile() throws IOException { | ||
| // Move temporary file (replace original if it exists) | ||
| // We implement the move as write into the original and delete the temporary one to keep file permissions etc. |
There was a problem hiding this comment.
Then hard-exiting JabRef during a write operation may leave the file corrupt and kind of defeats the purpose of the atomic writer.
There was a problem hiding this comment.
Note to self: I'll create an ADR. - The intended implementation fixes #8887.
|
Refs #6688, because users don't want that directory to be cluttered. |
|
Another more general thing I just came across as I looked into this saving issues again:
|
# Conflicts: # build.gradle # src/main/java/org/jabref/logic/exporter/AtomicFileOutputStream.java
# Conflicts: # CHANGELOG.md
… use line ending of library
# Conflicts: # src/main/java/org/jabref/gui/exporter/SaveDatabaseAction.java
Additionally - FileUtil vs. FileHelper comments Co-authored-by: Christoph <siedlerkiller@gmail.com> Co-authored-by: Carl Christian Snethlage <50491877+calixtus@users.noreply.github.com>
Co-authored-by: Christoph <siedlerkiller@gmail.com> Co-authored-by: Carl Christian Snethlage <50491877+calixtus@users.noreply.github.com>
Co-authored-by: Christoph <siedlerkiller@gmail.com> Co-authored-by: Carl Christian Snethlage <50491877+calixtus@users.noreply.github.com>
Co-authored-by: Carl Christian Snethlage <50491877+calixtus@users.noreply.github.com>
|
I did a bit of research how other (code) editors are handling this and was a bit surprised that vscode for example uses a simple write (not an atomic write). However, there are quite a few issues in the vscode repo about lost or corrupt files, see microsoft/vscode#98063 and linked issues. Other data points: visual studio uses atomic writer, sublime text has an option to toggle between them. While going through vscode's code, I found a few really nice implementations of things that JabRef is struggling with. They might be handy to be used as reference. In general, the vscode is very readable and well-structured; so worth looking at.
|
# Conflicts: # src/main/java/org/jabref/logic/autosaveandbackup/BackupManager.java # src/main/java/org/jabref/logic/exporter/AtomicFileOutputStream.java # src/main/java/org/jabref/logic/util/BackupFileType.java # src/main/java/org/jabref/logic/util/io/FileUtil.java # src/test/java/org/jabref/logic/autosaveandbackup/BackupManagerTest.java
|
|
||
| import org.jabref.logic.util.BackupFileType; | ||
| import org.jabref.logic.util.io.BackupFileUtil; | ||
| import org.jabref.logic.util.io.FileUtil; |
There was a problem hiding this comment.
🚫 [reviewdog] <com.puppycrawl.tools.checkstyle.checks.imports.UnusedImportsCheck> reported by reviewdog 🐶
Unused import - org.jabref.logic.util.io.FileUtil.
|
We fixed the AtomicFileOutputStream in summer. The discussions at #8750 (comment) show that we should re-iterate on the idea again. - Especially #7718 should be regarded. We close this PR and need to go back. The ADR https://github.com/JabRef/jabref/pull/8750/files#diff-123ad108d1738a32004ec352c9156e0088de245e0cb840687b658725c40bbf96 can still from a good basis for capturing the implementation decisions. |
Refs #8746
This introduces a feature of our
AtomicFileWriterto not "commit" changes if an error happened during write.I currently don't know how to test. Maybe simulating a small virtual hard disk not having enough space for writing?
should fix:
open things:
does not fix:
CHANGELOG.mddescribed in a way that is understandable for the average user (if applicable)