Dir.createFile fails when given a path containing . or .. on Windows 10

[jacquesh]

Consider the following program:

const std = @import("std");

pub fn main() !void {
    var test_file = try std.fs.cwd().createFile(".\\test.txt", .{});
    test_file.close();
}

This fails on my local machine running Windows 10 and the dev version of Zig from 2021-05-17 (I believe I checked this with 0.7.1 too and got the same behaviour). In particular it prints the following output:

B:\Work>zig run test.zig
error: FileNotFound
C:\Utilities\zig-windows-x86_64-0.8.0-dev.2275+8467373bb\lib\zig\std\os\windows.zig:120:39: 0x7ff7853dd753 in std.os.windows.OpenFile (test.obj)
            .OBJECT_PATH_NOT_FOUND => return error.FileNotFound,
                                      ^
C:\Utilities\zig-windows-x86_64-0.8.0-dev.2275+8467373bb\lib\zig\std\fs.zig:1019:23: 0x7ff7853d9a30 in std.fs.Dir::std.fs.Dir.createFileW (test.obj)
            .handle = try os.windows.OpenFile(sub_path_w, .{
                      ^
C:\Utilities\zig-windows-x86_64-0.8.0-dev.2275+8467373bb\lib\zig\std\fs.zig:908:13: 0x7ff7853d988a in std.fs.Dir::std.fs.Dir.createFile (test.obj)
            return self.createFileW(path_w.span(), flags);
            ^
B:\Work\test.zig:4:21: 0x7ff7853c30f6 in main (test.obj)
    var test_file = try std.fs.cwd().createFile(".\\test.txt", .{});
                    ^

If I remove the .\\ so that it reads just createFile("test.txt", .{}) then it works fine. If dir is a directory in the current directory then createFile("dir\\test.txt", .{}) also works, but createFile("..\\test.txt", .{}) does not. If I run the above code on https://zig.run it works without complaint.

Is this expected behaviour? I would generally expect .\test.txt to be exactly equivalent (as a path) to test.txt and I have not seen anything in the docs that stands out to me as obviously suggesting that this should not work.

For reference I tried a C program that used CreateFile with .\\test.txt as the given path and that worked so I'm fairly certain its not an issue of permissions or whatever that would cause file creation to legitimately fail.

[g-w1]

Probably a dupe of #6044