Windows fspy reports the workspace root as a read-write overlap and prevents caching

从 crates/vite_task/src/session/execute/tracked_accesses.rs 和 cache_update.rs 开始，跟踪 TrackedPathAccesses::from_raw 并观察 observe_fspy，以了解空的相对于 workspace 的路径如何变成重叠。复现 Windows 的 vite_task_bunx_wrapper::vite_task_bunx_wrapper 案例，并检查真实 Bun 进程树周围的 Windows 访问跟踪。当回归测试保留根目录输入跟踪，同时不修改 workspace 的访问不再阻止缓存时，即表示完成。

Summary

A cached task using the default automatic input and output inference completes successfully on Windows, but Vite Task refuses to store the cache entry because fspy reports the workspace root as both read and written.

The same fixture completes without this cache diagnostic on Linux and macOS.

Reproduction

This was captured by a real cross-platform Vite+ snapshot test added while working on voidzero-dev/vite-plus#2151.

• Failed Windows CI job: https://github.com/voidzero-dev/vite-plus/actions/runs/29151101121/job/86540717812
• Vite+ diagnostic commit: https://github.com/voidzero-dev/vite-plus/commit/919ed21669917a0e6e9d9a51167e7fb621f99bb9
• Vite Task revision used by that Vite+ build: cb580c214bb2314fc1f633a3812782c9b3a1d956
• Failing test: vite_task_bunx_wrapper::vite_task_bunx_wrapper

The fixture used a real managed Bun 1.3.14 installation rather than a mocked executable. Its configured task was equivalent to:

export default {
  run: {
    tasks: {
      'gate:test': {
        command: 'bun probe',
      },
    },
  },
}

The package script executed a real package binary through Bun:

{
  "scripts": {
    "probe": "bunx --bun probe"
  },
  "dependencies": {
    "probe-bin": "file:./probe-bin"
  },
  "devEngines": {
    "packageManager": {
      "name": "bun",
      "version": "1.3.14",
      "onFail": "download"
    }
  }
}

The snapshot steps were:

vp install
vp run gate:test
vp run --last-details

The command itself succeeded:

$ bun probe
$ bunx --bun probe
probe binary ran

Only the Windows run then reported:

vp run: vite-task-bunx-wrapper#gate:test not cached because it modified its input.

[1] vite-task-bunx-wrapper#gate:test: $ bun probe ✓
    → Not cached: read and wrote ''

The empty relative path is the workspace root. Re-running the task cannot hit the cache because no entry was stored.

Expected behavior

The task should be cacheable when the process tree does not actually modify an inferred input. In this fixture, a subsequent identical run should be able to hit the cache.

Actual behavior

On Windows, fspy reports the workspace root as both read and written. Vite Task treats the empty workspace-relative path as an input/output overlap and skips the cache update.

Analysis

TrackedPathAccesses::from_raw strips the workspace root from absolute paths. An access to the root itself therefore becomes an empty RelativePathBuf, which is retained in both path_reads and path_writes:

https://github.com/voidzero-dev/vite-task/blob/cb580c214bb2314fc1f633a3812782c9b3a1d956/crates/vite_task/src/session/execute/tracked_accesses.rs

observe_fspy then performs an exact intersection between the inferred read and write path sets. The empty path is returned as read_write_overlap, causing CacheNotUpdatedReason::InputModified:

https://github.com/voidzero-dev/vite-task/blob/cb580c214bb2314fc1f633a3812782c9b3a1d956/crates/vite_task/src/session/execute/cache_update.rs

One possible source of the false positive is the Windows access-mode mapping. The Windows preload records the requested access mask when intercepting NtCreateFile/NtOpenFile, before forwarding the real call. Directory access rights share bit values with FILE_WRITE_DATA and FILE_APPEND_DATA, so opening a directory with the capability to add children may be classified as a write even when the process does not mutate it.

The existing diagnostic only contains the aggregated path. It does not identify the originating PID/process, access mask, create disposition/options, or whether the intercepted call succeeded, so the exact syscall in the Bun process tree is not yet known.

A regression test should preserve real root-directory input tracking while ensuring that a directory-handle access which does not mutate the workspace does not make an otherwise cacheable Windows task permanently uncacheable.