Thanks for working on this!

I recently observed some weird behavior with relative symlinks created in pwsh.exe on windows. It went something like this:
a/b/c/external/file.x
a/b/c/out/x64/bin/link.x -> ../../../external/file.x
a/b/c/bin -> out/x64/bin
get-content bin/link.x : Error: a/external/file.x does not exist. (Ignoring the fact that link.x lives inside it symlink itself)

I'm not sure if this also works like this on linux and under which specific circumstances this occurs. Maybe the symlinks were made absolute for this reason. We have changed our PowerShell script to produce absolute symlinks (and disabled caching) to fix bazel-bin invocations.

@meteorcloudy Do you happen to know what's up with relative symlinks on Windows? I can add more test cases.

I recently observed some weird behavior with relative symlinks created in pwsh.exe on windows. It went something like this:
a/b/c/external/file.x
a/b/c/out/x64/bin/link.x -> ../../../external/file.x
a/b/c/bin -> out/x64/bin
get-content bin/link.x : Error: a/external/file.x does not exist. (Ignoring the fact that link.x lives inside it symlink itself)

This is probably due to

So given:

pcloudy@bazel-windows-playground:~/workdir/symlink_test
$ tree .
.
├── external
│   ├── bar -> /c/Users/pcloudy/workdir/symlink_test/vendor/bar
│   └── foo -> /c/Users/pcloudy/workdir/symlink_test/vendor/foo
└── vendor
    ├── bar
    │   └── file
    ├── external -> /c/Users/pcloudy/workdir/symlink_test/external
    └── foo
        └── link -> ../external/bar/file

We got different results based on which style of file path you use for cat (probably affects how symlinks in the path was resolved?).

pcloudy@bazel-windows-playground:~/workdir/symlink_test
$ cat c:/Users/pcloudy/workdir/symlink_test/external/foo/link
cat: 'c:/Users/pcloudy/workdir/symlink_test/external/foo/link': No such file or directory
pcloudy@bazel-windows-playground:~/workdir/symlink_test
$ cat /c/Users/pcloudy/workdir/symlink_test/external/foo/link
hi

So basically c:/Users/pcloudy/workdir/symlink_test/external/foo/link is resolved to

=> c:/Users/pcloudy/workdir/symlink_test/external/foo/../external/bar/file
=> c:/Users/pcloudy/workdir/symlink_test/external/external/bar/file ❌

but /c/Users/pcloudy/workdir/symlink_test/external/foo/link is resolved to

=> /c/Users/pcloudy/workdir/symlink_test/vendor/foo/link
=> /c/Users/pcloudy/workdir/symlink_test/vendor/foo/../external/bar/file
=> /c/Users/pcloudy/workdir/symlink_test/vendor/external/bar/file
=> /c/Users/pcloudy/workdir/symlink_test/external/bar/file
=> /c/Users/pcloudy/workdir/symlink_test/vendor/bar/file ✅

I think we might want to be a bit careful on opening up relative symlinks on Windows since they behave different due to this issue.

@meteorcloudy if I understand correctly, with the case you described that works on PWSH, further actions that use MSYS2 but with PWSH-style paths would fail. What if paths are converted so that

• in PWSH/Win32 API realm, paths are always like C:\...;
• in MSYS2 realm, paths are always like /c/...?

@pauldraper years ago you mentioned running ln to bypass this limitation. Are you still using this trick? Have you got into the aforementioned issue of link resolution being different?

Thank you for contributing to the Bazel repository! This pull request has been marked as stale since it has not had any activity in the last 30 days. It will be closed in the next 30 days unless any other activity occurs. If you think this PR is still relevant and should stay open, please post any comment here and the PR will no longer be marked as stale.