request: add option to call fsync() when closing files

[cjihrig]

What is the problem this feature will solve?

I believe it is possible that Node can close a file and then try to interact with the same file before all of the data has been written to disk. According to the docs for close(2) this can be fixed by calling fsync().

What is the feature you are proposing to solve the problem?

Add an option to the appropriate fs functions (close(), writeFile(), etc.) to call fsync() automatically.

What alternatives have you considered?

Flushing the data "by hand."

[aduh95]

/cc @nodejs/fs

[bnoordhuis]

For fs.writeFile() that makes sense, it's a sequence of system calls.

For fs.close() it makes less sense, IMO. Just call fs.fsync() before fs.close().

See also #28513 about interleaving fs.fsync() and fs.WriteStream.

[mcollina]

I think adding an option to fs.WriteStream would be helpful too.

@bnoordhuis as a side note, I have been experiencing significant read-after-write issues when using Node.js fs APIs since the move to IO_URING. It's too fast and the filesystem is not flushed.

[benjamingr]

I think writeFile and fs.WriteStream makes sense (especially writeFile)

[cjihrig]

In addition to writeFile() and fs.WriteStream, there are a few other APIs where this could make sense:

• appendFile() - calls writeFile() under the hood with a modified copy of its options. This one should Just Work™, but should include tests as well.
• truncate() - opens the file, calls ftruncate(), and then closes the file.
• lchmod() - opens the file, calls fchmod(), and then closes the file. I'm less sure if it is necessary here.
• copyFile() - this one is tricky because it is implemented several different ways in libuv and Node never has access to the file descriptor.