Apple Support directed me to the Developer Forums for this API-contract question. I am implementing conservative, read-only ACL classification for existing files and directories. I need to distinguish an absent ACL from unavailable or incomplete ACL information. Ambiguous results are currently rejected. The measurements below were taken on macOS 26.5, build 25F71, Apple Silicon (arm64), on APFS. Method I tested eight newly created objects: a regular file and a directory in each of four preparation states: Fresh: no ACL setter, deletion or normalization was performed. Explicit-empty ACL preparation. One DENY entry. One ALLOW entry. “Fresh” describes preparation only; I am not assuming it independently proves ACL absence. Each object remained open through preparation and two observations using the same file descriptor. Each observation performed: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_REPORT_FULLSIZE and without FSOPT_PACK_INVAL_ATTRS. Errno was cleared immediately before each query and captured immediately afterward. Descriptor/path identity and metadata stability were checked. Returned lengths, attribute bitmaps and applicable reference/payload bounds were validated. Observations Results matched between the two observations and between regular files and directories: Preparationacl_get_fd_np resultfgetattrlist returnEXTENDED_SECURITY returnedReturned filesec ACE countAttribute-buffer lengthFreshNULL, errno ENOENT0NoN/A32 bytesExplicit-emptyNULL, errno ENOENT0Yes076 bytesOne DENY entryNon-NULL, errno 00Yes1100 bytesOne ALLOW entryNon-NULL, errno 00Yes1100 bytesWhen the getter returned NULL, ACL validation and enumeration were not performed; their results are N/A, not measured zeros or an empty entry list. When EXTENDED_SECURITY was omitted, its payload fields were unavailable. I did not interpret default buffer values as returned ACL information. An actually returned zero-entry record is distinct from omission. No NOACL sentinel was observed in this experiment. Question For a valid descriptor referring to an existing APFS object, what is the supported interpretation of: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returning NULL with ENOENT; and fgetattrlist() succeeding while omitting ATTR_CMN_EXTENDED_SECURITY from the returned attribute bitmap? In particular: Can this combination establish ACL absence under documented conditions, or must it remain classified as unavailable/ambiguous information? How should the observed NULL/ENOENT with an actually returned zero-entry ACL record be interpreted? If these results cannot establish absence, which supported read-only, descriptor-based API or verification sequence should be used? What guarantees and limitations apply regarding macOS versions, filesystem support and genuine retrieval failures? I reviewed the acl_get(3) documentation but could not find a clear explanation of this valid-descriptor ENOENT case: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get.3.html I am seeking the supported API contract, not asserting an OS defect or vulnerability. I do not want to set, delete or normalize ACLs on the objects being inspected, or treat an ambiguous result as success.