Open hauserx opened 6 months ago
There is some code where bazel is creating junctions if cannot find target file:
Thanks for the detailed bug report!
I suspect the fix is simply:
- // Still Create a dangling junction if the target doesn't exist.
- if (!target.toFile().exists() || target.toFile().isDirectory()) {
- WindowsFileOperations.createJunction(link.toString(), target.toString());
+ if (createSymbolicLinks) {
+ WindowsFileOperations.createSymlink(link.toString(), target.toString());
} else {
- if (createSymbolicLinks) {
- WindowsFileOperations.createSymlink(link.toString(), target.toString());
+ // Still Create a dangling junction if the target doesn't exist.
+ if (!target.toFile().exists() || target.toFile().isDirectory()) {
+ WindowsFileOperations.createJunction(link.toString(), target.toString());
} else {
Files.copy(target, link);
}
...but I had no time yet to try it out and implement a test.
I believe this would fix the createSymbolicLinks=true
case. There's no hope for the other case; junctions are inherently different from symlinks (junctions can only point to directories, and they are always absolute), creating a dangling junction instead of a dangling symlink was just enough to fix https://github.com/bazelbuild/bazel/issues/2474 (in https://github.com/bazelbuild/bazel/commit/6c07525462062d491816a66a94c3db3b2dbc8f98).
The issue here is that, when building without the bytes, we create the symlink before the file it points to exists (it will be downloaded later if the symlink is ever consumed as an action input, or is itself materialized as an output).
The createSymbolicLink
implementation for Windows creates a junction if the target path doesn't exist, which will fail later because junctions can only point at directories, not files. As Laszlo points out above, we could make it work for the --windows_enable_symlinks
case, but that's not a complete solution since not everyone is able or willing to set this flag (it requires administrator privileges).
Possible solutions, in rough order of complexity:
--remote_download_minimal
. This must happen transitively since symlinks can point to other symlinks.
Description of the bug:
The issue seems to be that if built normally, the
builder_reset\builder.exe
created inrules_go
below throughctx.actions.symlink
(link) is a regular file when run without cache, but is JUNCTION when taken from remote cache.Looks like junctions for files do not work well under Windows.
Below reproduction on hello world example using rules_go: https://github.com/hauserx/rules-go-startup
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.
No response
Which operating system are you running Bazel on?
Windows
What is the output of
bazel info release
?release 7.1.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No response
Have you found anything relevant by searching the web?
Below bug describes some non-deterministic behavior with same symptoms. https://github.com/bazelbuild/bazel/issues/19018 In contrary this bug is fully reproducible and seems to be caused by build without bytes behavior.
Any other information, logs, or outputs that you want to share?
No response