Globing a deleted directory fails
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
When _path/to/project/BUILD_ contains a `glob(["**/*.cs"])` and _path/to/project/src/SomeFolder_ contains various *.cs files, a consequtive `bazel build` will result in errors when _SomeFolder_ is deleted.
### Environment
We are running on **windows** which could narrow down the impact. Also passing `--nowatchfs` fixes the error, but is not a solution we would like to push to all our devs.
### Errors
For bazel 7.x: `error globbing [**/*.cs] - [**/obj/**, **/bin/**] op=FILES: D:/dev/.../SomeFolder (No such file or directory`
For bazel 8.x: `Inconsistent filesystem operations. Encountered error 'D:/dev/.../SomeFolder (No such file or directory)' but didn't encounter it when doing the same thing earlier in the build The results of the build are not guaranteed to be correct. You should probably run 'bazel clean' and investigate the filesystem inconsistency (likely due to filesystem updates concurrent with the build)`
### Stack trace
```
[com.google.devtools.build.lib.packages.StarlarkNativeModule.runGlobOperation] Exception processing includes=[**/*.cs], excludes=[**/obj/**, **/bin/**])
java.io.FileNotFoundException: D:/dev/.../SomeFolder (No such file or directory)
at com.google.devtools.build.lib.vfs.JavaIoFileSystem.getDirectoryEntries(JavaIoFileSystem.java:96)
at com.google.devtools.build.lib.vfs.FileSystem.readdir(FileSystem.java:648)
at com.google.devtools.build.lib.vfs.Path.readdir(Path.java:268)
at com.google.devtools.build.lib.skyframe.DefaultSyscallCache.readdirImpl(DefaultSyscallCache.java:269)
at com.github.benmanes.caffeine.cache.LocalLoadingCache.lambda$newMappingFunction$3(LocalLoadingCache.java:197)
at com.github.benmanes.caffeine.cache.UnboundedLocalCache.lambda$computeIfAbsent$2(UnboundedLocalCache.java:296)
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(Unknown Source)
at com.github.benmanes.caffeine.cache.UnboundedLocalCache.computeIfAbsent(UnboundedLocalCache.java:292)
at com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
at com.github.benmanes.caffeine.cache.LocalLoadingCache.get(LocalLoadingCache.java:57)
at com.google.devtools.build.lib.skyframe.DefaultSyscallCache.readdir(DefaultSyscallCache.java:116)
at com.google.devtools.build.lib.vfs.SingleFileSystemSyscallCache.readdir(SingleFileSystemSyscallCache.java:52)
at com.google.devtools.build.lib.skyframe.DirectoryListingStateFunction.compute(DirectoryListingStateFunction.java:66)
at com.google.devtools.build.lib.skyframe.DirectoryListingStateFunction.compute(DirectoryListingStateFunction.java:32)
```
### 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.
_No response_
### Which operating system are you running Bazel on?
Windows
### What is the output of `bazel info release`?
release 7.4.1
### If `bazel info release` returns `development 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` ?
```text
```
### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
_No response_
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Start by tracing the reported glob path through StarlarkNativeModule.runGlobOperation, DefaultSyscallCache.readdir, and DirectoryListingStateFunction, then reproduce the Windows case with a globbed directory deleted between consecutive builds. Compare behavior with and without --nowatchfs; done means the subsequent build handles the deleted directory without the reported filesystem inconsistency or FileNotFoundException.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100