Description of the bug:

When running bazel --output_user_root=C:\_b clean --expunge in our Windows CI environment, we get the following error.

java.lang.UnsatisfiedLinkError: 'int com.google.devtools.build.lib.windows.WindowsFileOperations.nativeIsSymlinkOrJunction(java.lang.String, boolean[], java.lang.String[])'
	at com.google.devtools.build.lib.windows.WindowsFileOperations.nativeIsSymlinkOrJunction(Native Method)
	at com.google.devtools.build.lib.windows.WindowsFileOperations.isSymlinkOrJunction(WindowsFileOperations.java:141)
	at com.google.devtools.build.lib.windows.WindowsFileSystem.isSymlinkOrJunction(WindowsFileSystem.java:275)
	at com.google.devtools.build.lib.windows.WindowsFileSystem.fileIsSymbolicLink(WindowsFileSystem.java:135)
	at com.google.devtools.build.lib.windows.WindowsFileSystem.stat(WindowsFileSystem.java:158)
	at com.google.devtools.build.lib.vfs.FileSystem.statNullable(FileSystem.java:525)
	at com.google.devtools.build.lib.vfs.FileSystem.readdir(FileSystem.java:646)
	at com.google.devtools.build.lib.vfs.Path.readdir(Path.java:268)
	at com.google.devtools.build.lib.exec.BinTools.scanDirectoryRecursively(BinTools.java:132)
	at com.google.devtools.build.lib.exec.BinTools.forProduction(BinTools.java:80)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.newRuntime(BlazeRuntime.java:1299)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.serverMain(BlazeRuntime.java:1024)
	at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:769)
	at com.google.devtools.build.lib.bazel.Bazel.main(Bazel.java:95)

Oddly, our regular bazel test command succeeds, when run immediately after. The only difference in configuration I can think of is that the bazel test command is invoked with --nosystem_rc. Our system rc file just contains startup --output_user_root=C:\\_b, so I don't think it makes a difference for this purpose.

Which category does this issue belong to?

No response

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

The command that fails is:

bazel --output_user_root=C:\_b clean --expunge

I'm not sure what causes this. I've seen it happen in our CI environment, but not when that command is run directly from a shell. I couldn't reproduce it on a dev machine.

Which operating system are you running Bazel on?

Windows Server 2022, on x86_64

What is the output of bazel info release?

release 8.0.0-pre.20231030.2

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

This is via Bazelisk v1.19.0.

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

n/a

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Not sure. We first saw this about a week after we upgraded from 7.0.0-pre.20230926.1 to 8.0.0-pre.20231030.2.

Have you found anything relevant by searching the web?

#19250 has the same error message, but that happened on ARM64 whereas I'm seeing this on x86_64. It also seems like that was more consistently reproducible.

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

cc @meteorcloudy in case you might know something from #19250 which would affect x86_64 too.