Ok, it's been awhile since I could get time to come back to this!

I've added a basic test. PTAL.

OK, PTAL.

I fixed the buildifier presubmit failure.

The other failure looks unrelated -- I get the same error at clean head. It's specific to the rolling version of bazel and something about workspace support.

Actually, I partially take that back -- The LTS windows test is failing. Some quick searches indicates windows symlink support should work fine with the values the test is using (relative symlinks that point nowhere).

Diagnosing and fixing this will be a bit hard, but I'll see what I can do. If it comes to it, can we simply mark this test to skip windows?

https://bazel.build/configure/windows#symlink
Do you have --windows_enable_symlinks specified as a startup flag? Otherwise a junction might be created instead of a symlink, which doesn't support relative path.

See https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/windows/WindowsFileSystem.java;l=83-92

I tried adding --windows_enable_symlinks, but that didn't fix it.

So far, all I can tell is that, when tar building occurs, and python calls os.readlink() to figure out the value contained in the symlink, it gets back an absolute path e.g. \\?\C:\b\3ctu2esx\execroot\_main\bazel-out\x64_windows-fastbuild\bin\tests\tar\link1. That is the correct resolved path (foo_link1 -> ./link1), but yeah, we don't want the resolved path.

I can't tell which of these cases is happening:

1. Bazel is writing an absolute path
2. Windows is silently transforming it to an absolute path at write
3. Windows is silently transforming it to an absolute path at read
4. Python is transforming it to an absolute path

I won't have direct access to a windows machine until this evening, so I'll have to wait until then to check some of these ideas.

But overall, this isn't sounding promising. I don't think we can work around (1) or (2). A work around for (3) and (4) might be possible by using e.g. ctypes and dropping into lower-level APIs.

After testing on my personal windows machine, I'm thinking its (1: Bazel writing an absolute path). I can use mklink to create relative symlinks, and python's os.readlink() returns the relative path correctly. When I use an absolute path, it returns a \\?\... looking string, the same as what I'm observing.

Aha, here we go. known issue in Bazel specific to windows: bazelbuild/bazel#14224

OK, I guess let's disable the test on Windows for now

Tests fixed. PTAL

bump -- this has been sitting for awhile; is there an ETA on when someone can review?

bump -- this has been sitting for awhile; is there an ETA on when someone can review?

In the future, if you hit the "Re-request review" button, that will let the reviewer who has left comments look at the PR again. Looking now

Oh, i had not noticed that thingy before. Done, for at least my own practice :). Thanks!