os: O_SYNC not utilized in os.OpenFile() on Windows

[aschmahmann]

While Linux systems are able to pass their low level flags directly into os.OpenFile on Windows os.OpenFile takes "invented values"

go/src/syscall/types_windows.go

Lines 34 to 48 in 5d1a951

	const (
	// Invented values to support what package os expects.
	O_RDONLY = 0x00000
	O_WRONLY = 0x00001
	O_RDWR = 0x00002
	O_CREAT = 0x00040
	O_EXCL = 0x00080
	O_NOCTTY = 0x00100
	O_TRUNC = 0x00200
	O_NONBLOCK = 0x00800
	O_APPEND = 0x00400
	O_SYNC = 0x01000
	O_ASYNC = 0x02000
	O_CLOEXEC = 0x80000
	)

These invented values are then checked against a subset of the features that Windows actually supports in syscall.Open

go/src/syscall/syscall_windows.go

Line 273 in 03aca99

func Open(path string, mode int, perm uint32) (fd Handle, err error) {

Despite Windows supporting FILE_FLAG_WRITE_THROUGH (very close to O_SYNC on Linux) the Open function does not check for O_SYNC. This is unexpected behavior as developers would expect the O_SYNC flag on Windows to work since it can perform synchronous writes.

Some ways to resolve this unexpected behavior include:

• Adding a check for O_SYNC in syscall.Open in syscall_windows.go
• Having syscall.Open perform on Windows the same way it does on Linux, by passing in file flags directly
  • Note: This solution would also help with proposal: syscall: define Windows O_ALLOW_DELETE for use in os.OpenFile #34681

[networkimprov]

cc @alexbrainman @zx2c4 @mattn
@gopherbot add OS-Windows

[alexbrainman]

Thank you for creating this issue.

I am not an expert here. But, I am not against mapping syscall.O_SYNC onto FILE_FLAG_WRITE_THROUGH.

Alex

[tsellers-r7]

Are there data loss concerns related to this issue. For example, expecting O_SYNC force writes to disk before returning but instead the OS is caching the writes?

[aschmahmann]

@tsellers-r7 my understanding is the answer is "sort of".

go/src/os/file.go

Lines 68 to 81 in 03aca99

	// Flags to OpenFile wrapping those of the underlying system. Not all
	// flags may be implemented on a given system.
	const (
	// Exactly one of O_RDONLY, O_WRONLY, or O_RDWR must be specified.
	O_RDONLY int = syscall.O_RDONLY // open the file read-only.
	O_WRONLY int = syscall.O_WRONLY // open the file write-only.
	O_RDWR int = syscall.O_RDWR // open the file read-write.
	// The remaining values may be or'ed in to control behavior.
	O_APPEND int = syscall.O_APPEND // append data to the file when writing.
	O_CREATE int = syscall.O_CREAT // create a new file if none exists.
	O_EXCL int = syscall.O_EXCL // used with O_CREATE, file must not exist.
	O_SYNC int = syscall.O_SYNC // open for synchronous I/O.
	O_TRUNC int = syscall.O_TRUNC // truncate regular writable file when opened.
	)

The comment here states that not all flags are passed/utilized on every platform. However, if you assumed that O_SYNC worked on your platform (which wouldn't be unreasonable on Windows given the existence of FILE_FLAG_WRITE_THROUGH) and turned out to be incorrect you could experience unexpected data loss (as in hypermodeinc/badger#1084).

[alexbrainman]

However, if you assumed that O_SYNC worked on your platform (which wouldn't be unreasonable on Windows given the existence of FILE_FLAG_WRITE_THROUGH) and turned out to be incorrect you could experience unexpected data loss (as in dgraph-io/badger#1084).

I don't see any promise of data loss prevention in O_SYNC documentation.

It says

O_SYNC int = syscall.O_SYNC // open for synchronous I/O.

whatever that means.

Alex

[aschmahmann]

Fair enough, I guess I was referring to the Linux O_SYNC documentation http://man7.org/linux/man-pages/man2/open.2.html.

@alexbrainman you're absolutely correct that there aren't any Go contracts/documentation currently being violated. However, if a user isn't really sure what O_SYNC's synchronous I/O means they'll probably reach for something similar, like the link above.

[networkimprov]

The point of O_SYNC or write-through is to leave the file cache untouched, usually because the file to be written should not be added to the cache, for example in a backup scenario.

[ianlancetaylor]

@networkimprov That sounds like like O_DIRECT. O_SYNC means that writes will not return until the data has been sent to the underlying hardware. (Although modern smart disks will themselves buffer the data, so even that is not necessarily a guarantee.)

[networkimprov]

Oh, yes, O_SYNC makes write() become write() + fsync().

[zx2c4]

We have:

nix:

• O_SYNC
• O_DIRECT

win:

• FILE_FLAG_NO_BUFFERING
• FILE_FLAG_WRITE_THROUGH

Documentation on FILE_FLAG_NO_BUFFERING: https://docs.microsoft.com/en-us/windows/win32/fileio/file-buffering
Documentation on FILE_FLAG_WRITE_THROUGH: https://docs.microsoft.com/en-us/windows/win32/fileio/file-caching

Quick perusal makes me think that the closet approximation is actually O_SYNC=FILE_FLAG_WRITE_THROUGH, O_DIRECT=FILE_FLAG_NO_BUFFERING. Does this correspond with other folks' reading too?

Note that we'll probably never match the exact semantics, but we can find something that's reasonably close, I wouldn't mind making such a mapping in Go.