This market resolves YES if, on or before December 31, 2026 (America/Los_Angeles), Apple’s public, non-beta documentation and corresponding macOS/Xcode SDKs show that FSKit (or its renamed successor) provides a public user-space filesystem API with all of the following:
Read-write mounting: A third-party FSKit module can mount a local, read-write filesystem that is accessible via normal POSIX paths (no private/Apple-internal entitlements; standard FSKit entitlement is acceptable).
Core POSIX semantics: Documented support for creating, reading, writing, and deleting files and directories; renames; hard links and symlinks; Unix permissions and ACLs (or documented macOS equivalent); and extended attributes. (Sparse files supported if documented, but not required for resolution.)
Durability primitives: A documented mechanism to honor fsync/FDATASYNC (or an explicitly documented equivalent) so a filesystem can provide crash-consistent persistence semantics.
Public availability: The relevant APIs are marked public (not beta/preview), included in a shipping macOS release and its Xcode SDK by the deadline, and usable by third parties with the standard FSKit entitlement.
Notes
The market resolves solely on Apple’s public docs/headers/release notes; no third-party implementations or demos are required. But a third-party ZFS for MacOS implementation would be sufficient to show that the API has the necessary features.
If any required capability above is missing or only available via private APIs or kernel extensions by the deadline, resolves NO.
If FSKit is renamed but clearly remains Apple’s user-space filesystem framework, treat it as FSKit.
1,000