windows: use permissive file share flags everywhere

[gvilums]

On windows, the zig standard library generally uses pretty restrictive FILE_SHARE_* flags, even though there is no obvious reason to do so.

This PR changes all uses to the most permissive share flags, allowing other processes to read, write and delete files that are opened by the running process, and allowing the running process to open files that may have already been opened with more permissive sharing permissions. This is in line with POSIX behavior, and I see no reason not to allow this, as it is not required for correctness in any of the cases (from my understanding, please correct me if I'm wrong here).

The prompt for opening this PR was a set of issues we have been facing at bun: For example, deleting a directory that has been opened with fs.openDir would result in an error.Unexpected NTSTATUS=0xc0000043 (a STATUS_SHARING_VIOLATION).

For reference, note that the rust standard library uses the most permissive flags for all file opening operations: click, click

[Jarred-Sumner]

Relevant GitHub issues likely caused by a combination of this + undefined behavior occurring after the usage of unreachable:

• index out of bounds installing dependencies on windows oven-sh/bun#9808
• Can not install dependencies, error: ENOENT installing react oven-sh/bun#9456
• bun install crashes with attempt to unwrap error oven-sh/bun#9835
• running bun create results in an error oven-sh/bun#9833
• Running bun install fails on windows (NtSetInformationFile()) oven-sh/bun#9830
• bun add is not working on windows 10 oven-sh/bun#9815
• Bun crashes when using create with an invalid package oven-sh/bun#9837

[jdalton]

We should add a trivial test to validate.

[kubkon]

How come you had to revert this change? Do you know why CreateNamedPipeFile is failing with your change?

[chawyehsu]

I guess because NtCreateNamedPipeFile does not support FILE_SHARE_DELETE.

[e4m2]

@kubkon

CreatePipe() was implemented recently in #19271 as (hopefully) an exact match of the same function in kernel32.
I think all changes to that function should be reverted. There is no extra issue here that could possibly arise with Zig's current flags that the vast majority of other software that just directly calls the kernel32 implementation also wouldn't have.

(The \Device\Null and \??\MountPointManager changes probably deserve a closer look too)

---

@chawyehsu

Please don't link to leaked source code without a warning (or at all).

Not everyone checks where the link leads before clicking on it, and even if they did, they might not recognize why it's a bad idea in this case.
Even just having this here could make it harder for people to contribute to Windows-related stuff in Zig, especially when it comes to working towards #1840 and similar issues.
ReactOS has had constant issues with this since its inception - I think we better err on the side of caution here. Thanks.