Repository navigation
Copy a folder on another disk onto that disk instead of refusing it - #189
Conversation
Box the rarely set removed_from of each inode, keep only directories in the core's path-to-entry cache (files are one listing lookup further), share that cache's keys with the entries' own, shrink the inode table once the kernel forgets most of it, and cap a git mount's recent whole file reads at 64 MiB. A 200k-file walk goes from 147 MB to 89 MB with the same walk times. With files out of the path-entry cache, a recheck of a shrunk file changes only its listing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013jkdGETmgGUb8hcSEpppQK
Files clone only within one disk, so a fork of a plain folder on another disk used to fail with CrossDevice unless allow_copy made a full copy. Its frozen copy now goes in .sandfs/copies at the top of the folder's own disk, registered in the home's copies-elsewhere file, and is cleaned up with the home's other copies. The .sandfs folder is left out of forks of that disk's top. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013jkdGETmgGUb8hcSEpppQK
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
Security findingsAdvisory findings (1)ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: de7fcf0ad9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ttributes A full copy (allow_copy) opened each copied file read-only to set its modification time, which Windows refuses, and opened folders without backup semantics, which Windows can't. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013jkdGETmgGUb8hcSEpppQK
…disk's top A .sandfs or .sandfs/copies at a disk's top that is a link could point into the folder being copied, which would then copy into itself; such a disk's copies stay in the home. A folder's own .sandfs/copies, away from a disk's top, is listed as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013jkdGETmgGUb8hcSEpppQK
There was a problem hiding this comment.
🛡️ Codex Security Review · Automatically triggered
Here are some automated security review suggestions for this pull request.
Reviewed commit: 60966cd304
ℹ️ About Codex security reviews in GitHub
This is an experimental Codex feature. Security reviews are triggered when:
- You comment "@codex security review"
- A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review
Once complete, Codex will leave suggestions, or a comment if no findings are found.
Anyone who could write .sandfs or .sandfs/copies at a disk's top, or rename them there, could swap a home's folder for a link, and copies would be written, and deleted, wherever it led. Those folders must be the home owner's and writable by no one else, at a top that is not writable by others or is sticky; otherwise the copy stays in the home, and cleanup leaves such a folder alone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013jkdGETmgGUb8hcSEpppQK
Wave 3 of the over-mode safety plan, the frozen-copies part.
What changes
Files clone only within one disk. Before this change, forking a plain folder on another disk (an external drive, a second volume, tmpfs) failed with
CrossDeviceunlessallow_copymade a full copy. Now its frozen copy goes on the folder's own disk, so it is still a clone and costs almost no space:<disk top>/.sandfs/copies/home-XXXX/copy-YYYY.disk_topfinds the top by walking up the path's ancestors while they stay on the same device.copies-elsewherefile lists each of those folders, soholds_copyandremove_unused_copiessee every copy. Empty folders on other disks are removed, along with.sandfs/copiesand.sandfswhen those end up empty. A disk that is unplugged keeps its entry. The list is rewritten through a temp file and a rename..sandfsfolder can't be made (the disk is read-only, say), the copy falls back to the home's copies folder and the old rules apply..sandfsout of its listing (gitfile::FolderSource) and out of its frozen copy, so a copy never copies other copies.Core API / behaviour
Error::CrossDevicenow comes up much less often: only when the copy really can't clone (for example tmpfs to tmpfs givesEOPNOTSUPP, and the error says it can't clone). The docs forallow_copyandCrossDevice, the CLI's--allow-copyhelp, the README and the changelog are updated to match.clone_treegains askipargument, and its CrossDevice check now compares against the device of the copy's own folder.Tests
a_folder_on_another_disk_is_copied_on_that_diskreplaces the old refusal test; there is also a newa_folder_s_copies_of_its_disk_are_never_copied.the_copies_at_a_disk_s_top_are_left_out_of_its_listing.a_fork_of_a_folder_on_another_disk_is_a_copy_on_that_disk, run on /dev/shm.-D warnings, and the fmt check passes.The branch also carries a
-s oursmerge of the old branch head (already merged as #188), so the push could fast-forward. The diff against main is only this change.Generated by Claude Code