Symlink creation broken on Windows

[cameron-martin]

Description of the bug:

On Windows, when creating symlinks to a directory using ctx.actions.declare_symlink and ctx.actions.symlink, symlinks are created that are unusable since they are not created as directory symlinks. From a brief look through the code in Bazel that creates symlinks, symlinks shouldn’t be allowed to be created to directories on windows, requiring junctions instead.

This is causing rules_js to be unusable on Windows with newer versions of Bazel. See aspect-build/rules_js#2261.

Which category does this issue belong to?

Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I’ve created a reproducer here: bazel-symlink-bug-main.tar.gz

The test can be run using bazel test //:test_mode.

Which operating system are you running Bazel on?

Windows

What is the output of bazel info release?

release 8.3.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

N/a

What's the output of git remote get-url origin; git rev-parse HEAD ?

N/a

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

c3ad87e

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

No

[fmeum]

Before the linked commit, "symlinks" to non-existent files didn't work since they were created as junctions. After the commit, "symlinks" to non-existent directories are created as regular symlinks and thus don't work.

It looks like we have to track the intended target type of an "unresolved" symlink, that is, one declared via ctx.actions.declare_directory. Unless we find a way to have a type-independent symlink-like object on Windows.

CC @tjgq @meteorcloudy

[tjgq]

I think the simplest solution given the constraints might be something along these lines:

1. Add a FileSystem#createSymbolicLink overload receiving a "type hint"
2. Modify WindowsFileSystem#createSymbolicLink to create the junction/symlink appropriately based on the hint (other filesystems may use a default implementation that ignores the hint)
3. Modify RemoteActionFileSystem to detect the case when the symlink target path matches one of the action's inputs, and use the type of that input (as given by its metadata, i.e., without examining the on-disk state) as the hint when calling FileSystem#createSymbolicLink.

I don't have the time to work on this right now, but I'd happily review a PR.

[tjgq]

Oh, but this only works if the symlink target is a declare_directory or declare_file. If it's a target path it cannot work, because the target won't be an input to the action that creates the symlink.

[cameron-martin]

Oh, but this only works if the symlink target is a declare_directory or declare_file.

It's possible that rules_js could be modified to not use target_path, and use target_file instead, although I don't have context behind that choice.

What if either ctx.actions.symlink or ctx.actions.declare_symlink were to take a type hint? Would that be viable?

[tjgq]

If nothing else works, adding a hint argument to ctx.actions.symlink doesn't sound entirely unreasonable; I'd make it so you can only use it with declare_symlink, since for declare_file/declare_directory there's an obviously correct choice that we should be able to make as described above. But that's also a question for the Rules API subteam.

Can we first get to the bottom of why rules_js is unable to use target_file?

[cameron-martin]

cc @gregmagolan since you seemed to have written that code in rules_js.