Write-ahead Logging #23
Comments
macguru
pushed a commit
to ulyssesapp/zipzap
that referenced
this issue
Jul 18, 2020
…raph-styles to feature/docx * commit '11887a076d6a6d540ef12575d80cc7c57368f445': (30 commits) Final changes for ULYSSES-4819 according to code review Adds test case for default paragraph style Minor refactoring Removes whitespace Renames some variables Major refactoring Adds support for orphan control Adds test case for orphan control Adds support for hyphenation Adds hyphenation test case Adds context parameter to string processing methods Adds support for keep-with-following Adds test case for keep-with-following Adds support for default tab interval Adds test case for default tab interval Adds support for custom tab stops Adds test case for custom tab stops Replaces kCTTextAlignment with RKTextAlignment Replaces NSTextAlignment with kCTTextAlignment Adds support for spacing attribute ...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've moved this over from #9 to its own issue
We want to have some form of WAL to avoid zip file corruption on writing out data. At this stage I'm not sure whether I want to make it explicit in the API -- which adds to cognitive overhead for using zipzap -- or try for a transparent solution which can fail in common edge cases like some other process or event changing the zip file between recording the WAL and reapplying the WAL.
Since @79f31f7, we write first to temp files (or data) then attempt to apply the temp files to the original file. This temp file could serve as a WAL with some sort of link from the original to the temp file e.g. via
xattr. If and when the app crashes when applying the temp file, the link will still be present and can be automatically applied when the file is opened again.This should be configurable via init parameters for users that don't want the overhead of a WAL.
Would appreciate your thoughts and feedback!
The text was updated successfully, but these errors were encountered: