atomic_write_file: rename-based write does not preserve platform ACLs, xattrs, or owner/group

[dean0x]

Summary

atomic_write_file in crates/mds-cli/src/output.rs uses a write-to-tempfile + rename pattern, which is correct for atomic content replacement. This pattern has one won't-fix limitation by construction and two open platform-specific issues.

Won't fix: hard links

rename replaces the directory entry atomically. Any other hard links to the original inode continue to point to the old content — the file at path now has a new inode with link count 1. Hard-link preservation is incompatible with a rename-based atomic write; this is not a bug but a fundamental property of the approach. Documented in the function's doc comment (PR #239).

Open: platform ACL and xattr preservation

1. ACLs lost on macOS/Linux: Extended ACL entries on the original file are not copied to the temp file before rename.
2. xattrs lost: Extended attributes (used by macOS Finder metadata, security.selinux on SELinux/AppArmor, etc.) are not copied to the temp file.
3. Owner/group not preserved: The temp file is created with the process's effective UID/GID. If the original file was owned by a different user (e.g., a root-owned config), the rename replaces the owner rather than restoring it.

These do not manifest in the common case (user writing their own file, no special labels). They become issues in environments with SELinux/AppArmor file labels or macOS systems where quarantine bits or Finder metadata are attached to files.

Proposed fix

For environments that require ACL/xattr preservation, use platform-specific copy APIs (e.g., copyfile(3) on macOS, copy_file_range + setxattr on Linux) to transfer attributes from the original to the temp file before rename.

References

• Introduced in PR fix: v0.4.0 remediation — dogfooding blockers, bug batch, UX polish, docs sweep #196 (commit 168a58a)
• Related: atomic_write_file: metadata() failure silently yields mode 0600 via .ok() #225 (metadata() silent fallback)
• Documentation fix: PR doc: add note about atomic_write_file not preserving hard links, ACLs, xattrs, owner/group #239

[dean0x]

The documentation acceptance criterion is satisfied by PR #239, which added the limitations to the doc comment at crates/mds-cli/src/output.rs:445-447. The issue body has been rewritten to reflect what remains: platform-specific ACL/xattr/owner-group preservation. Hard-link preservation is noted as won't-fix by construction.

[dean0x]

Closing as documented contract (v0.4.3, C4).

atomic_write_file stays replace-by-rename (same-directory temp file + rename after a final symlink re-check). Consequence, now stated as a contract rather than a runbook note: a pre-existing target's hard links (other links keep the old content), ACLs, extended attributes, and owner/group are not preserved; permission bits are restored on Unix. With #227 this covers mds build / mds watch compiled outputs and .map sidecars as well as the mds fmt / mds lint --fix source rewrites. (Source rewrites are fsynced before the rename; compiled outputs and sidecars rely on the rename alone — see the Durability split in PR #385.)

Where it is documented:

• spec.md §7.2, "Output writing" paragraph (normative, user-facing)
• SECURITY.md, "Filesystem boundary" bullet "Replace-by-rename writes"
• crates/mds-cli/src/output.rs, atomic_write_file rustdoc
• RELEASING.md, Notes
• CHANGELOG.md, Unreleased / Internal

Disposition:

• Hard-link preservation: won't-fix by construction — keeping the inode would require truncate-then-write in place, which forfeits the crash/full-disk safety the helper exists to provide.
• ACL / xattr / owner-group preservation: not planned. MDS only rewrites its own outputs and .mds sources; a workflow that needs those attributes should regenerate them after the write.