Zig fmt fails to open local-path files

[BarabasGitHub]

Zig 0.5.0+6a0927d8c on Windows

The file window.zig exists, but these fail. Just using zig fmt window.zig works fine.

PS C:\Projects\ZigVulkan> zig fmt .\window.zig
unable to open '.\window.zig': error.FileNotFound
PS C:\Projects\ZigVulkan> zig fmt ./window.zig
unable to open './window.zig': error.BadPathName

For the second one I guess it's the same as #2668

[squeek502]

As far as I can tell, NtCreateFile treats ObjectName literally and doesn't do any resolving, so it's actually searching for the impossible path C:\Projects\ZigVulkan\.\window.zig. To fix this particular issue, it seems like either paths need to always be resolved before calls to std.fs.openFileWindows or resolved within std.fs.openFileWindows (and other callers of NtCreateFile?).

Also worth noting that .. as a directory in ObjectName is invalid and gives an STATUS_OBJECT_NAME_INVALID error (0xC0000033):

• zig fmt ..\test.zig -> error.Unexpected NTSTATUS=0xc0000033
• zig fmt test\..\test.zig -> error.Unexpected NTSTATUS=0xc0000033
• zig fmt test..\test.zig -> error.FileNotFound (accurate, that file didn't exist)

[daurnimator]

Pre-resolving has huge implications for following symlinks (called/using "reparse points" in NT-speak). I don't think its required, but will need to do some research.

[squeek502]

Tiny reproduction:

const std = @import("std");

test "windows open file" {
    var first = try std.fs.cwd().openFile("test.zig", .{});
    first.close();

    var second = try std.fs.cwd().openFile(".\\test.zig", .{});
    second.close();
}

If test.zig exists, the first open succeeds, but the second fails, even though they would resolve to the same path.

[daurnimator]

So I did some research, and processing '..' on windows requires a dance where you use NtQueryInformationFile + NtOpenFile to traverse up a directory for each time you encounter '..'.
There is an example at: https://git.midipix.org/ntapi/tree/src/fs/ntapi_tt_open_physical_parent_directory.c

[squeek502]

This can be closed now (fixed by #5187)