b348276
Merge pull request #60 from zed-industries/fix-failures
Click to expand commit body
Fix more test flakiness
Antonio Scandurra
created
37f0ba9
Increase timeout for fs-dependent conditions
Antonio Scandurra
created
4884a05
Change buffer atomically when reloading from disk
Antonio Scandurra
created
19f51bc
Rely more on conditions for state derived after worktree changes
Antonio Scandurra
created
2c43066
Merge pull request #59 from zed-industries/more-resilient-fs-events
Click to expand commit body
Use `flush_fs_events` more after performing synchronous fs mutations
Antonio Scandurra
created
eea9cb4
Use `flush_fs_events` more after performing synchronous fs mutations
Click to expand commit body
I am not sure I have caught all the examples of this, but in general
I think we always want to perform a `flush_fs_events` as opposed to
`next_scan_complete` when doing synchronous I/O. Indeed, the file
system may inform us about the events caused by the just-performed
I/O over multiple batches, and `next_scan_complete` may return
before seeing all of them.
Note that this also removes a few assertions which were ensuring
that, on start, a worktree's file handle wouldn't know its deleted
status, even if the file didn't exist for sure on disk. However,
now that `file` is an async API, it's possible that by the time the
`FileHandle` is resolved, `Worktree` has already completed scanning.
We test a similar behavior further along in the test where those
assertions were removed, so it felt okay to proceed without them.
Antonio Scandurra
created
0187b6d
Merge pull request #54 from zed-industries/file-changed-on-disk
Click to expand commit body
Handle buffers' files changing on disk from outside of Zed
Max Brunsfeld
created
520cbfb
Read file's mtime in background when getting a FileHandle