Synchronize files after writing #10735
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fsync(2) is a somewhat expensive operation that flushes writes to the underlying disk/SSD. It's typically used by databases to ensure that writes survive very hard failure scenarios like your cat kicking the plug out of the wall. Synchronizing isn't automatically done by `flush`ing (from the `std::io::Write` or `tokio::io::AsyncWriteExt` traits). From the [`tokio::fs::File`] moduledocs: > To ensure that a file is closed immediately when it is dropped, you > should call `flush` before dropping it. Note that this does not ensure > that the file has been fully written to disk; the operating system > might keep the changes around in an in-memory buffer. See the > `sync_all` method for telling the OS to write the data to disk. [`tokio::fs::File`]: https://docs.rs/tokio/latest/tokio/fs/struct.File.html
|
This looks to be what Neovim does too, so it was an oversight on my part: https://github.com/neovim/neovim/blob/4e5c633ed4871a948aff7338b793ac5f93484153/src/nvim/bufwrite.c#L1619-L1634 |
|
I think we should be calling fsync after restoring the backup since that's where it's called in the linked code. |
|
I'll be trying this fix. My computers crash or run out of battery pretty often sadly xP |
|
@kirawi where do you mean? I'm not familiar with the neovim codebase but it looks to me like they're calling fsync after writing and before performing any renaming or permissions/metadata changes |
|
Oh yeah, you're right. |
pascalkuthe
approved these changes
May 13, 2024
Vulpesx
pushed a commit
to Vulpesx/helix
that referenced
this pull request
Jun 7, 2024
fsync(2) is a somewhat expensive operation that flushes writes to the underlying disk/SSD. It's typically used by databases to ensure that writes survive very hard failure scenarios like your cat kicking the plug out of the wall. Synchronizing isn't automatically done by `flush`ing (from the `std::io::Write` or `tokio::io::AsyncWriteExt` traits). From the [`tokio::fs::File`] moduledocs: > To ensure that a file is closed immediately when it is dropped, you > should call `flush` before dropping it. Note that this does not ensure > that the file has been fully written to disk; the operating system > might keep the changes around in an in-memory buffer. See the > `sync_all` method for telling the OS to write the data to disk. [`tokio::fs::File`]: https://docs.rs/tokio/latest/tokio/fs/struct.File.html
kirawi
pushed a commit
to kirawi/helix
that referenced
this pull request
Jun 9, 2024
fsync(2) is a somewhat expensive operation that flushes writes to the underlying disk/SSD. It's typically used by databases to ensure that writes survive very hard failure scenarios like your cat kicking the plug out of the wall. Synchronizing isn't automatically done by `flush`ing (from the `std::io::Write` or `tokio::io::AsyncWriteExt` traits). From the [`tokio::fs::File`] moduledocs: > To ensure that a file is closed immediately when it is dropped, you > should call `flush` before dropping it. Note that this does not ensure > that the file has been fully written to disk; the operating system > might keep the changes around in an in-memory buffer. See the > `sync_all` method for telling the OS to write the data to disk. [`tokio::fs::File`]: https://docs.rs/tokio/latest/tokio/fs/struct.File.html
Chirikumbrah
pushed a commit
to Chirikumbrah/helix
that referenced
this pull request
Jun 15, 2024
fsync(2) is a somewhat expensive operation that flushes writes to the underlying disk/SSD. It's typically used by databases to ensure that writes survive very hard failure scenarios like your cat kicking the plug out of the wall. Synchronizing isn't automatically done by `flush`ing (from the `std::io::Write` or `tokio::io::AsyncWriteExt` traits). From the [`tokio::fs::File`] moduledocs: > To ensure that a file is closed immediately when it is dropped, you > should call `flush` before dropping it. Note that this does not ensure > that the file has been fully written to disk; the operating system > might keep the changes around in an in-memory buffer. See the > `sync_all` method for telling the OS to write the data to disk. [`tokio::fs::File`]: https://docs.rs/tokio/latest/tokio/fs/struct.File.html
|
@EriKWDev how has this patch been faring for you? I'd be thrilled to hear if you haven't been seeing empty files after your computer dies |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fsync(2) is a somewhat expensive operation that flushes writes to the underlying disk/SSD. It's typically used by databases to ensure that writes survive very hard failure scenarios like your cat kicking the plug out of the wall. Synchronizing isn't automatically done by
flushing (from thestd::io::Writeortokio::io::AsyncWriteExttraits). From thetokio::fs::Filemoduledocs:This seems like a likely fix for #7618 (comment).