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.