Repository navigation
Fix Go apply/vendor on Windows read-only module cache (#346) - #1351
Merged
Mikola Lysenko (mikolalysenko) merged 5 commits intoOct 9, 2026
Merged
Conversation
Go extracts module-cache files read-only, and on Windows that is the read-only attribute. apply and vendor copy the module out of the cache and patch the copy with stage + rename, but Windows refuses to rename over a read-only file, so every Go apply/vendor on Windows failed with "Access is denied. (os error 5)" and nothing was patched. fresh_copy now grants owner-write on each copied file that arrived read-only. The copy is a fresh private inode, so the module cache and any shared inode keep their permissions. Fixes #346 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
BugBot review |
Mikola Lysenko (mikolalysenko)
enabled auto-merge
October 9, 2026 17:23
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 6830b65. Configure here.
Tanmay Singla (Tanmay182003)
approved these changes
Oct 9, 2026
Mikola Lysenko (mikolalysenko)
removed this pull request from the merge queue due to a manual request
Oct 9, 2026
Mikola Lysenko (mikolalysenko)
enabled auto-merge
October 9, 2026 21:32
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 9, 2026
The merge group failed `cargo check --all-targets` (lib test target): the read-only module-cache test added by this PR called apply_go_redirect with 11 arguments, but #1049 ("Remove --download-mode and the diff download path") removed the `uuid: Option<&str>` parameter on main. Pass the current 10-argument signature; behavior and test coverage are unchanged. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Mikola Lysenko (mikolalysenko)
enabled auto-merge
October 9, 2026 22:26
Mikola Lysenko (mikolalysenko)
deleted the
agent/v5-go-windows-readonly-copy
branch
October 9, 2026 23:26
Mikola Lysenko (mikolalysenko)
added a commit
that referenced
this pull request
Oct 9, 2026
Picks up #1351 (Go read-only module cache); no conflicts. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
LLM Description written by Claude Code:claude-opus-5-5
Fixes #346
Summary
On Windows, Go
apply(agent mode) andvendorfailed on every module withAccess is denied. (os error 5). Now the copied module is writable and the patch applies.Root cause
Go extracts module-cache files read-only, which on Windows means the
Rattribute.copy_tree::fresh_copycopies the module into.socket/go-patches/…or.socket/vendor/golang/<uuid>/…withstd::fs::copy, which carries the attribute over. The apply pipeline then commits patched bytes with stage + rename, and Windows'MoveFileEx(REPLACE_EXISTING)refuses to replace a read-only destination. On Unix, rename ignores the target's mode, which is why only Windows failed.Fix
fresh_copygrants owner-write to each copied file that arrives read-only. On Unix it adds0o200; on Windows it clears the read-only attribute. It only touches the fresh inodestd::fs::copyjust wrote, never the source or a link, so the module cache and any shared inode keep their permissions. Both Go backends (agentapply_go_redirectandvendor_go_module) share this copy step.I fixed the copy rather than the rename. Clearing the attribute in
stage_and_renamewould change the attribute on the displaced inode, which can be a hardlinked store file.Tests (red → green)
copy_tree::tests::fresh_copy_files_are_writable_even_from_readonly_source: on unpatched code it fails on every platform (the copy is0o444/ read-only). It passes with the fix.golang_local::tests::test_apply_redirect_over_a_read_only_module_cache: the fixture cache files are marked read-only (set_readonly(true)), and apply runs for both the go-patches base and a vendor base. It checks that the copy is patched and that the cache stays read-only and pristine. This is the Windows reproduction, so the Windowstestlegs are where it would have failed before the fix.Commands run
cargo test -p socket-patch-core --lib -- copy_tree golang_local: 56 passedcargo clippy --workspace --all-features -- -D warnings: cleancargo fmt --all -- --check: the changed files are clean (the only diff is pre-existing, inupstream/mod.rson main)🤖 Generated with Claude Code
Note
Low Risk
Localized filesystem permission fix on private copy inodes with regression tests; does not change auth, patching logic, or source cache permissions.
Overview
Fixes #346: Go apply/vendor on Windows failed with access denied because module-cache copies kept the read-only attribute from
std::fs::copy, and the patch pipeline’s stage+rename could not replace read-only destinations on Windows.fresh_copynow callsmake_owner_writableafter each copied file: on Unix it ORs0o200; on Windows it clears the read-only attribute. Only the newly created copy inode is touched—the module cache stays read-only.Docs on
fresh_copyare updated to explain Windows vs Unix behavior. Tests cover writable copies from read-only sources andapply_go_redirectover read-only cache files for both go-patches and vendor copy bases.Reviewed by Cursor Bugbot for commit 6830b65. Configure here.
Generated by Claude Code