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

fuseops/ops.go

@@ -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

samples/flushfs/flush_fs_test.go

@@ -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() {