You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix CAS inode corruption: directory cache cleanup must not chmod files (#2347)
Port of TraceMachina/nativelink PR #2243 commit a47774d.
Root cause: when DirectoryCache evicts an entry, the cleanup path calls
`set_readwrite_recursive` on the cached tree before `remove_dir_all`. That
helper chmods every entry — including files — to 0o755/0o644. Files in
a cached entry are hardlinked into in-flight action workspaces (via
`hardlink_directory_tree` in `get_or_create`) and ultimately share an
inode with the underlying `FilesystemStore` CAS blob (via `fs::hard_link`
in `download_to_directory`). Chmoding the cached-side file therefore
silently mutates the shared inode's mode for every other in-flight
action holding a hardlink to the same blob.
Production symptom: EACCES on exec for `cc_wrapper.sh`. The CAS mode of
0o555 (r-xr-xr-x) gets clobbered to 0o644 (rw-r--r--), dropping the +x
bit while an unrelated action is mid-exec.
Fix: introduce `set_dir_writable_recursive` which only chmods
directories, never files. On unix, write permission on the parent
directory is sufficient to unlink files inside; the files' own modes
are irrelevant for unlinking. Switch the eviction cleanup path in
`DirectoryCache::evict_lru` to the new helper.
Empirically verified: a regression test that hardlinks a 0o555 file
into a cached tree and runs the cleanup helper FAILS on pre-fix code
(file mode mutated to 0o644) and PASSES on post-fix code.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments