Executable-variant cache (.exec) is not tracked by max_bytes and never evicted at runtime #2474

Summary

FilesystemStore maintains a per-digest on-disk executable-variant cache at {content_path}.exec, but those variants are never inserted into evicting_map. As a result they are not counted against max_bytes and are never reclaimed at runtime — the only cleanup is a remove_dir_all of the directory on store startup. On a worker doing executable-heavy input materialization, .exec grows ≈1:1 with the real CAS, roughly doubling the on-disk footprint and driving the host past max_bytes until it runs out of disk.

Details

In nativelink-store/src/filesystem_store.rs:

• get_executable_hardlink_source → create_executable_variant does a std::fs::copy of the 0o444 CAS blob into {content_path}.exec/d/{digest} and chmods it 0o555.
• The variant is never added to evicting_map, so it is invisible to max_bytes accounting.
• The only reclamation is fs::remove_dir_all({content_path}.exec) at store startup. There is no runtime eviction, no size cap, and no config flag to gate the behavior.

Impact

On long-lived workers, disk usage climbs monotonically past max_bytes until the host hits a disk-full / disk-pressure condition (e.g. pod eviction in Kubernetes).

Origin

Introduced with the executable-variant materialization path added to fix the ETXTBSY / "Text file busy" race (#2366, addressing #2362).