O_NOFOLLOW|O_PATH is more or less the same as O_SYMLINK: it gives you a handle on a symlink. But there are semantic differences including in how you make use of it. O_NOFOLLOW by itself is useful for secure applications; O_PATH more or less mandates system-specific code that we tend to either not support or fold into POSIX or Win32 support.
O_NOFOLLOW is distinct from O_SYMLINK in that O_NOFOLLOW will error if the given path includes a symlink. That’s why i think it’s useful to expose, just as a new kind of failure mode that applications may want to account for.
The file locking flags are a minefield: they don't mean the same thing on Windows vs. POSIX, and may have semantic differences between POSIX platforms. It's better to use the low level calls as described above if you need locking, since you can then write the appropriate code for the platform and your use case.
This makes sense; i wasn’t familiar with the file locking APIs, so it’s important to know that they vary between platforms. This is also why i suggested allowing platform-support libraries to expose their specific set of IOFlags.
I should also add that I have no idea whether O_NOFOLLOW exists on Windows, or how it would be implemented on an old-style "symlink" / NTFS reparse point. This may again force it into system dependent code, especially in the latter case.
The MSVC POSIX compatibility implementation of `open()` does not define the O_NOFOLLOW flag, so if you're looking for whether Windows supports it, that's probably a good indicator: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open-wopen?... But i was under the impression that MSYS was used on Windows, which defines a Linux-equivalent version of `open()`. I'm not sure how MSYS deals with O_NOFOLLOW, though. Thanks, Victoria Mitchell