`Dir.makePath` handles `..` in the sub_path differently per-platform

[squeek502]

Zig Version

0.12.0-dev.2018+9a56228c2

Steps to Reproduce and Observed Behavior

From a test in #17499 (cc @rootbeer):

test "makepath relative walks" {
    if (builtin.os.tag == .wasi) return error.SkipZigTest;

    var tmp = tmpDir(.{});
    defer tmp.cleanup();

    const relPath = try fs.path.join(testing.allocator, &.{
        "first", "..", "second", "..", "third", "..", "first", "A", "..", "B", "..", "C",
    });
    defer testing.allocator.free(relPath);

    try tmp.dir.makePath(relPath);

    // verify created directories exist:
    try expectDir(tmp.dir, "first" ++ fs.path.sep_str ++ "A");
    try expectDir(tmp.dir, "first" ++ fs.path.sep_str ++ "B");
    try expectDir(tmp.dir, "first" ++ fs.path.sep_str ++ "C");
    try expectDir(tmp.dir, "second");
    try expectDir(tmp.dir, "third");
}

• On Linux, this test passes (it creates the ./first/A, ./first/B, ./first/C, ./second, and ./third directories)
  • This seems to be due to first/../second being treated as different from second (i.e. .. are not resolved before passing the path to mkdirat)
  • Very likely related: symlinks and ".." directories and platforms oh my! #7751 and std.fs.realpath bugs/inconsistencies on Windows #4658
• On Windows, this test fails (it only creates ./first/C)
  • This is due to .. being collapsed/resolved during sliceToPrefixedFilePathW before being passed to NtCreateFile (related: Relative paths on Windows: when to resolve . and .. ? #4659)
• Other platforms have not been tested

Expected Behavior

All platforms to have similar behavior

[squeek502]

An additional note: the Linux behavior here matches the behavior of mkdir -p on Linux:

$ ls
$ mkdir -p first/../second/../third
$ ls
first  second  third

So this seems to basically be the same dilemma as #7751 and #4658 (comment)

[andrewrk]

One possible solution is to merely document the differences in platform behavior and leave it to the API user to handle the differences appropriately. For example, some of the file system API mentions that atomicity is platform-dependent.

I think the most important concern is 1. making it practical to write optimal software that does the best combination of syscalls on any given OS, closely followed by 2. making it maintainable to do this for all the supported operating systems being abstracted over.

In other words, I would rather solve the problem by pushing the OS differences onto the API user, than do a bunch of work behind the scenes to make one system emulate a different one.

[squeek502]

Agreed, I think that's the most viable path forward for something like this where trying to hammer one platform's behavior to match the shape of another would likely incur a significant 'optimality' penalty in one direction or another. Plus, matching the platform convention for each platform doesn't seem like the worst thing in this case.

Can always revisit this decision later if there's more context that's missing.