Configuration being evaluated: macOS 15.4.1 (24E263), Apple silicon, Apple's native APFS, and an existing executable that calls fsync(fd) on an already-open regular file. This is the selected configuration for our question, not a claim that a new runtime qualification has been completed.
We need to preserve the executable's original call semantics and the native APFS target. We are not proposing a replacement filesystem, a modified fsync implementation in the executable, or a private kernel patch.
Is there a documented, customer-deployable interface for synchronously rejecting this particular fsync request before the filesystem accepts or begins the synchronization work attributable to that request?
The critical schedule is: an initial check allows the request; execution is delayed; a deadline expires or the originating thread/operation loses its authorization; the request then tries to begin. We need to know whether a supported interface can prevent that still-unstarted request from proceeding, rather than merely report an error after it has begun.
If such an interface exists, please identify:
- The API and supported OS versions, including availability on the configuration above, plus any entitlement, component, signing, or deployment requirements.
- The precise event where allow/deny takes effect, and the caller, file-object, and request identity available there, including an already-open descriptor.
- Whether authorization remains revocable after an allow response and before execution. If any timing guarantee is offered, its exact interval, assumptions, and documented bound.
- Whether denial, an enforcement timeout, or loss of the enforcing component prevents this request's synchronization work, or can occur after that work has started.
We distinguish request admission, filesystem execution, return, and persistence completion. We do not assume that an earlier authorization marker is the execution boundary. We are asking about work attributable to this request, not unrelated background writeback, and are not asking for a bound on completion of an already-started fsync.
We will separately evaluate how any documented platform guarantees can be bound to our application's authority and lifetime rules. If no supported interface provides the stated control on this configuration, please confirm that scope. If a route requires a different OS version, executable, filesystem, or deployment policy, please identify that change explicitly.
This is an API/support-scope question; no proprietary source code or project archive is attached.
