In a synthetic reproduction of a DeviceSupport-style backup on macOS 26.7.1 with Xcode 26.6 on Apple silicon, a source object has no com.apple.provenance, while a newly created destination object acquires that private extended attribute. File contents, modes, ACLs, and the source's other extended-attribute names can be verified independently. The backup acceptance contract requires a future restore to reproduce the original governed metadata. Is destination creation expected to add this attribute? For a faithful restore to a fresh APFS destination, should restoration software omit it, remove it after creation, preserve it, or allow macOS to regenerate it? Which supported API or documented postconditions establish restoration fidelity when the source lacked the attribute? Could the attribute affect DeviceSupport symbol usability or access behavior? We are seeking Apple-supported backup and restoration procedures and security postconditions, not an interpretation of private metadata. No real DeviceSupport files, raw private attribute values, production paths, credentials, datasets, or personal information are included.

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, several directories in a development tree carry the private extended-attribute names com.apple.fileprovider.dir#N and com.apple.fileprovider.fpfs#P. On this host, the supported xattr_flags_from_name decoder returns XATTR_FLAG_NEVER_PRESERVE for the first exact name and XATTR_FLAG_NO_EXPORT for the second exact name. Apple's public API defines those flag meanings; the literal name encoding and the attributes' private values are not treated as a public semantic contract. We want a self-contained APFS compilation-input tree using descriptor-based COPYFILE_DATA for regular files, with independent inventory and hash verification and no private-xattr copying. For this compilation-only export, does Apple support deliberate non-preservation when xattr_flags_from_name returns XATTR_FLAG_NEVER_PRESERVE, and when it returns XATTR_FLAG_NO_EXPORT for a governed SHARE operation? Separately, what public, non-hydrating API can establish that every required file is already fully materialized and that export will not trigger provider downloads? Does enumeratorForMaterializedItems establish that state for a closed descendant tree, or must each item be checked by another supported API? Can reading or hashing an item itself cause materialization? We are asking about documented APIs, supported export behavior, and security postconditions. We are not asking to decode or preserve private attribute values. No production paths, source code, credentials, datasets, or personal information are included.

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, a small set of ordinary development source/resource files and one project directory carry the private extended attribute com.apple.macl. We need to create a new APFS compilation-input tree, not a filesystem backup. The proposed implementation opens source and destination objects using descriptor-relative no-follow traversal and calls fcopyfile(sourceFD, destinationFD, NULL, COPYFILE_DATA), then independently verifies exact content hashes and applies an explicit destination mode and ACL policy. It does not request COPYFILE_XATTR, COPYFILE_ACL, or COPYFILE_STAT. Is omitting com.apple.macl supported for this data-only compilation export? Could preserving it transfer stale or inappropriate access authority to the destination? Which supported API or documented postconditions should establish the destination's correct security state? Is there an Apple-recommended procedure for exporting ordinary development source content without transferring private mandatory-access metadata? We are seeking an API and security contract, not an interpretation of the attribute's private bytes. No production paths, source code, private attribute values, credentials, datasets, or personal information are included.