Skip to content

feat: dune-cache on windows via vhdx#33

Draft
yosefAlsuhaibani wants to merge 4 commits into
yosef/dune-cache-agressivefrom
yosef/dune-cache-by-vhdx
Draft

feat: dune-cache on windows via vhdx#33
yosefAlsuhaibani wants to merge 4 commits into
yosef/dune-cache-agressivefrom
yosef/dune-cache-by-vhdx

Conversation

@yosefAlsuhaibani

Copy link
Copy Markdown

No description provided.

Copy link
Copy Markdown
Author

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

yosefAlsuhaibani and others added 3 commits June 16, 2026 16:26
The cache extraction (tar | zstd -d) is not sparse-aware, so restore
writes the full logical size of the dynamic VHDX. A 50 GiB ceiling made
every restore materialize ~50 GiB of zeros, stalling the job. Size the
image to just above the real dune cache instead.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mounting the cache volume at an NTFS folder mount-point (a reparse
point) gave dune's copy-mode cache cleanup "rmdir: Directory not empty"
failures. Assign a drive letter instead so the cache temp dir is a plain
volume path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The drive-letter mount did not resolve dune copy-mode's
"rmdir: Directory not empty" on store, ruling out reparse-point
semantics. The remaining likely cause is Defender real-time scanning
holding a transient (delete-pending) handle on a just-written cache
file. Exclude the cache volume and report Defender status so we can
confirm whether it is active.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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