Commit b2c33963 authored by Aaron Jacobs's avatar Aaron Jacobs

Update state around "close without msyc" behavior on OS X.

parent d66bad87
......@@ -696,9 +696,10 @@ type SyncFileOp struct {
// * On OS X, if a user modifies a mapped file via the mapping before
// closing the file with close(2), the WriteFileOps for the modifications
// may not be received before the FlushFileOp for the close(2) (cf.
// http://goo.gl/kVmNcx).
// https://github.com/osxfuse/osxfuse/issues/202). It appears that this may
// be fixed in osxfuse 3 (cf. https://goo.gl/rtvbko).
//
// * However, even on OS X you can arrange for writes via a mapping to be
// * However, you safely can arrange for writes via a mapping to be
// flushed by calling msync(2) followed by close(2). On OS X msync(2)
// will cause a WriteFileOps to go through and close(2) will cause a
// FlushFile as usual (cf. http://goo.gl/kVmNcx). On Linux, msync(2) does
......
......@@ -605,19 +605,13 @@ func (t *NoErrorsTest) Mmap_NoMsync_MunmapBeforeClose() {
ExpectThat(t.getFlushes(), ElementsAre())
ExpectThat(t.getFsyncs(), ElementsAre())
// Close the file. We should see a flush. On Darwin, this will contain out of
// date contents (cf. https://github.com/osxfuse/osxfuse/issues/202).
// Close the file. We should see a flush with up to date contents.
err = t.f1.Close()
t.f1 = nil
AssertEq(nil, err)
if isDarwin {
ExpectThat(t.getFlushes(), ElementsAre("taco"))
ExpectThat(t.getFsyncs(), ElementsAre())
} else {
ExpectThat(t.getFlushes(), ElementsAre("paco"))
ExpectThat(t.getFsyncs(), ElementsAre())
}
ExpectThat(t.getFlushes(), ElementsAre("paco"))
ExpectThat(t.getFsyncs(), ElementsAre())
}
func (t *NoErrorsTest) Mmap_NoMsync_CloseBeforeMunmap() {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment