László Csomor
László Csomor
The bug only affects sandboxed execution. Without sandbox: ``` $ bazel clean ; bazel test --noenable_runfiles --build_runfile_manifests --spawn_strategy=standalone -t- --test_output=all //:x ... ==================== Test output for //:x: RUNFILES_MANIFEST_ONLY=1 RUNFILES_MANIFEST_FILE=/usr/local/google/.../x.runfiles/MANIFEST RUNFILES_DIR=/usr/local/google/.../x.runfiles...
Also, `RUNFILES_DIR` should not have a value with `--noenable_runfiles`.
Still repro'able with `release 6.0.0-pre.20220608.2`
Can we fix that?
@lberki : Why do you suppose it fails on Windows? Is there a test case I could try on Windows?
Thanks! The test fails here: https://github.com/bazelbuild/bazel/blob/b1e232d6f1d82494639660e8a2772ac7da7c5da8/src/test/shell/bazel/bazel_unresolved_symlink_test.sh#L243 ...because the build succeeds though it shouldn't. (Note: I edited the test to use `c:/badsymlink` instead of `/badsymlink`.)
~The culprit is~ I think the culprit is that WindowsFileSystem does not create file symlinks: https://github.com/bazelbuild/bazel/blob/b1e232d6f1d82494639660e8a2772ac7da7c5da8/src/main/java/com/google/devtools/build/lib/windows/WindowsFileSystem.java#L85-L89
@lberki : `test_file_instead_of_symlink ` breaks on Linux if I add `--spawn_strategy=standalone` to the `bazel` calls.
/cc @meteorcloudy @hlopko
/cc @laszlocsomor