Out of curiosity, why? In general, if you're writing to a file, you want to check for an f.Close() error. As long as you do that, I don't think a call to f.Sync() is necessary.

@mvdan Closing a file doesn't issue a sync. At the same time, there are plenty of files for which you won't care, and syncing unnecessarily will incur a performance cost. Maybe this is a documentation issue and no change to the code should be made.

My bad - I thought closing a file meant syncing it too, but I must have gotten confused. It's a bit bizarre that you could care about close errors but not about sync errors, though.

Some discussion about f.Sync in WriteFile has been discussed in the past. See #17869.

While it may seem reasonable for f.Sync to be called in your use case, it not reasonable to inflict the cost of f.Sync upon every use of it. You can always work around this, by creating the file yourself and writing to it and then calling Sync.

This is indeed a documentation issue.

We can document the lack of fsync for Go 1.10 unless somebody sends a change for Go 1.9 which would be fine too.

That is an odd sort of documentation to write. There are all kinds of functions that do not call os.File.Sync. Perhaps my expectations are wrong, but I would expect the reverse: I would expect that if ioutil.WriteFile called Sync, that that would be called out in the documentation. I would not expect the documentation to explicitly say that it does not call Sync.

I would agree, but this keeps coming up, so it makes me wonder if my expectations are wrong.

But I'm also fine not doing anything here again.

Lots of things don't call sync. This is not one worth singling out. I say stet.

Okay, fair enough. Closing.