Skip to content

fix(fspy): don't treat deleting a file as reading it on Windows - #980

Merged
wan9chi merged 1 commit into
mainfrom
fix-windows-delete-as-read
Nov 9, 2026
Merged

wan9chi merged 1 commit into
mainfrom
fix-windows-delete-as-read

Conversation

@wan9chi

@wan9chi wan9chi commented Nov 9, 2026 •

Copy link
Copy Markdown
Member

Motivation

On Windows, vp run records the files a task deletes as files it read. Deleting a file opens it with DELETE access and no data access. DeleteFileW, RemoveDirectoryW, Rust's remove_dir_all, libuv's unlink, and the MSVC STL's remove (which Node's rmSync uses) all do this, and so does MoveFileExW for a rename's source. fspy classifies every open without write access as a read.

So when a build cleans its output folder and writes it again, every output that existed beforehand becomes an inferred input. The cache fingerprints it as the task left it. If anything then changes that file before the next run, the next run misses with '<file>' modified, though the task never read it. Examples are a later step stamping a version into the output, or an earlier build in the same job leaving different content. On Linux and macOS, unlink, rmdir and a rename's source aren't recorded, so the same task hits there.

We hit this while replaying a monorepo's CI history against the remote cache. One task starts with rmSync(dist/runtime) and rebuilds the folder, and a later uncached step stamps the commit into its manifest. Across 200 Windows pushes, that task missed on the manifest 101 times, 90 of them in runs where the same task hit on Ubuntu. Each miss cost 9–12 s on the Windows critical path.

Changes

  • An open that asks for DELETE and no data access (FILE_READ_DATA, FILE_WRITE_DATA, FILE_APPEND_DATA, FILE_EXECUTE, any GENERIC_* right, or MAXIMUM_ALLOWED) is no longer recorded, as on Unix. Recording it as a write instead would make deleted paths outputs, and the folders above them written in, which Unix doesn't do.
  • Every other open is classified as before. DELETE together with read access is still a read, attribute-only opens such as a stat are still reads, and FILE_DELETE_ON_CLOSE needs no check of its own because it requires DELETE.
  • CreateSymbolicLinkW creates a file link with such an open, so that open is no longer recorded either; the reparse point it then sets is still recorded as a write. The Windows symlink_destination test now checks that a file link is recorded only as a write.
  • New e2e case output_changed_after_clean_and_rebuild: an earlier build leaves an output, the cached task deletes its output folder and writes it again, an uncached step changes the output, and the next run hits and restores the task's output. It failed on Windows before this change with cache miss: 'out/a.txt' modified, and passed on Linux and macOS.

🤖 Generated with Claude Code


Note

Medium Risk
Changes how Windows infers task inputs for caching; misclassification could still cause wrong hits or misses, though behavior is intentionally aligned with Unix and is well-tested.

Overview
Windows file-access tracking no longer records opens that request DELETE without data access, matching Unix behavior where unlink, rmdir, and rename sources are not tracked. Previously those opens were classified as reads, so tasks that clean an output folder (e.g. rmSync(dist)) incorrectly fingerprinted pre-existing outputs as inputs and could miss the cache when another step later changed those files.

The NT hook path now treats access_mask_to_mode as Option<AccessMode> and handle_open skips recording when the mask is delete-only (including typical DeleteFileW / remove_dir_all patterns). Symbolic link creation is aligned too: CreateSymbolicLinkW's delete-only open is ignored while the reparse-point write is still recorded.

Coverage adds unit tests for delete-only masks, tweaks the symlink std test on Windows, a new e2e case (output_changed_after_clean_and_rebuild) expecting a cache hit after an uncached stamp step, and a changelog entry.

Reviewed by Cursor Bugbot for commit e14ae71. Bugbot is set up for automated code reviews on this repo. Configure here.

Deleting a file or folder on Windows opens it with DELETE access and no
access to its data. DeleteFileW, RemoveDirectoryW, std's remove_dir_all,
libuv's unlink and the MSVC STL's remove, which Node's rmSync uses, all
do this, and MoveFileExW opens a rename's source the same way. fspy
recorded every open without write access as a read, so the deleted
paths became inferred inputs of the task.

When the task then wrote such a path again, as a build does after
cleaning its output folder, the input was fingerprinted as the task left
it. A later step that changed the file, such as one stamping a version
into the output, made the next run miss with "'<file>' modified", though
the task never read the file. On Unix, unlink, rmdir and a rename's
source aren't recorded, so the same task hit there.

An open that asks for DELETE and no data access is now not recorded,
as on Unix. Recording it as a write instead would make deleted paths
outputs and the folders above them written in, which Unix doesn't do.
FILE_DELETE_ON_CLOSE requires DELETE, so it needs no check of its own:
a temporary file deleted on close is still a read or a write by its
data access. Opens that only query attributes, such as a stat, are
still reads.

CreateSymbolicLinkW creates a file link with such an open, which is no
longer recorded either; the reparse point it then sets is still
recorded as a write.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown

fspy benchmark

linux

dynamic/launch             change  +0.57%  [ -2.83% ..  +3.49%]  overhead   +54.94%
dynamic/access             change  +1.16%  [ -2.79% ..  +4.04%]  overhead   +21.03%
dynamic/access-relative    change  -0.60%  [ -3.25% ..  +2.09%]  overhead   +70.32%
dynamic/access-contended   change  +0.00%  [ -6.22% ..  +4.79%]  overhead   +43.79%
static/launch              change  +0.40%  [ -2.19% ..  +3.74%]  overhead  +200.98%
static/access              change  -0.00%  [ -0.94% ..  +0.94%]  overhead +1469.86%
static/access-relative     change  -0.17%  [ -1.02% ..  +0.96%]  overhead +1958.70%
static/access-contended    change  +0.17%  [ -0.51% ..  +0.99%]  overhead +1592.68%

macos

dynamic/launch             change  -0.84%  [ -6.16% ..  +5.18%]  overhead  +253.74%
dynamic/access             change  +1.80%  [ -8.52% .. +157.29%]  overhead    +1.72%
dynamic/access-relative    change  -0.79%  [-10.59% ..  +4.74%]  overhead  +248.36%
dynamic/access-contended   change  +0.65%  [ -7.68% ..  +6.55%]  overhead    +6.63%

windows

dynamic/launch             change  +0.02%  [ -3.89% ..  +2.83%]  overhead   +27.22%
dynamic/access             change  +0.38%  [ -0.55% ..  +1.48%]  overhead    +1.47%
dynamic/access-relative    change  -0.18%  [ -1.59% ..  +1.27%]  overhead    +1.09%
dynamic/access-contended   change  +0.00%  [ -1.98% ..  +0.92%]  overhead    +1.44%

@wan9chi
wan9chi merged commit 9dba722 into main Nov 9, 2026
23 checks passed
@wan9chi
wan9chi deleted the fix-windows-delete-as-read branch November 9, 2026 07:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant