Re: Adding new contructors to IOMode to support "don't overwrite if already exists" behavior

[Victoria Mitchell]

> 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?view=vs-2019

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