Hi Kevin, Thank you for the detailed response and the code example. This is very helpful. Your confirmation that macOS currently has no supported API for creating a hard link directly from an open file descriptor resolves our primary question. We also understand your suggested approach of using ATTR_CMN_FSID, ATTR_CMN_FILEID, and ATTR_FILE_LINKCOUNT to detect whether the resulting hard link references the intended object. However, our security requirement is specifically to prevent an unauthorized filesystem mutation, rather than detect one afterward. In our threat model, another process operating under the same user account may concurrently replace the source pathname. If linkat() creates a hard link to that substituted object, detecting the mismatch afterward would not satisfy our requirement because the unauthorized mutation has already occurred. I would appreciate clarification on two final points: Regarding your suggestion to validate a file privately and then publish it using renameat() with RENAME_EXCL or RENAME_SWAP: Is there a supported mechanism that guarantees the published object is the exact previously validated inode, even when another process under the same user account can concurrently modify the source directory? Our requirement also includes retaining the original directory entry, rather than moving or replacing it. If no such mechanism exists, would it be accurate to conclude that macOS currently provides no supported public API or filesystem mechanism that guarantees race-free, same-object hard-link publication under this specific same-user adversarial threat model? We want to ensure we are not overlooking a supported macOS capability before considering a different execution platform. Thank you again for your guidance.