The recovery proofs assume exact successful bytes-and-length flush fences, restart quiescence, discoverable evidence and exclusive cooperating ownership. This document records the host obligations behind those assumptions. It does not qualify a filesystem or device for power-loss recovery. E4/F6/I15 remain open.
StreamPageStore.FlushAsync(true) calls FileStream.Flush(true) for a FileStream. Other streams receive their own FlushAsync; the Boolean request does not give an arbitrary stream device-flush semantics. PhysicalRollback.BeginWrite creates persistent recovery evidence only for the file-stream path. In-memory captures and temporary spill files on other paths support rollback within that lifecycle; they do not provide a persistent identity, discovery or reopen protocol.
Journal preparation/records, replacement copies/decisions and ownership receipts flush file contents. Creation, movement, replacement and deletion also change names. The net11.0 library asset on Windows uses DirectoryPersistence to flush writable parent-directory handles after journal promotion, prepared evidence publication, selected destination publication and ordered retirement. The adapter uses the source-audited backup-semantics option and immediately checks cleared/captured last-error state; a suppressed access-denied result is a failed acknowledgement. The standard asset and other platforms have no directory adapter and retain process-only guarantees.
An acknowledged directory operation is still conditional on the deployed runtime, filesystem and device contracts. It does not itself qualify name discovery after physical power loss. A process kill exercises recovery code but leaves the host, its caches and outstanding device work alive.
A failed flush grants no successful fence. Retain the surviving evidence and distinguish an uncertain decision from a confirmed rollback. The buffered model permits finite reordered/torn persistence before failure; its restart transition additionally assumes that retired effects cannot later overwrite recovery. Tests that throw from a managed flush do not qualify this host contract. The buffered content refinement additionally requires authorization for zeros exposed by reordered reextension before a durable replay marker. An old write persisting after truncation can preserve exact undo evidence while leaving an unrecorded zero gap that production refuses without mutation. Qualification must establish this zero-exposure contract, or a separately justified protocol must handle such survivors; undo recoverability alone does not establish parser admission or recovery availability.
The public FileStream.Flush(Boolean) contract covers intermediate file buffers; it does not specify a parent-directory barrier. The following table preserves the original source audit pinned to the .NET v10.0.0 reference implementation; the native Windows adapter’s .NET 11 RC3 review follows below. Source review is evidence about the named implementation, not a guarantee for every runtime that can load the netstandard2.1 asset. Qualification must record the actual runtime build and repeat the relevant audit.
| Host boundary | Reference evidence | Remaining obligation |
|---|---|---|
| Windows file flush | FileStreamHelpers.Windows.FlushToDisk invokes FlushFileBuffers; its access-denied handling also means an exception-free call alone is not a universal successful-fence witness. The Win32 contract concerns the specified file handle. |
Qualify writable regular-file handles, name persistence and ordering for the actual filesystem, volume, controller and device. Do not infer directory durability from this call. |
| Linux file flush | FileStreamHelpers.Unix.FlushToDisk invokes the runtime synchronization shim. SystemNative_FSync uses fsync outside its macOS branch. Linux documents a separate directory synchronization requirement. |
Establish directory-entry ordering, successful regular-file synchronization and restart quiescence; qualify mount/storage configuration and error behavior. |
| macOS file flush | The same pinned runtime shim selects F_FULLFSYNC when built with TARGET_OSX and HAVE_F_FULLFSYNC. Apple distinguishes this operation from ordinary fsync. The managed Unix helper can ignore unsupported-synchronization errors. |
Verify the deployed build selects the expected operation and the filesystem supports it. File synchronization alone does not establish this protocol’s name lifecycle or cooperating lock semantics. |
The production Windows adapter uses File.OpenHandle with the unnamed
(FileOptions)0x02000000 backup option, writable access and retained sharing,
then RandomAccess.FlushToDisk with an immediate last-error check. The reviewed
handle acquisition
forwards that option, while the
10.0.14 flush helper
suppresses access-denied errors unless the adapter checks them. This is a narrow
source-audited Windows path, not a named portable BCL directory-barrier contract.
Standard/Linux/macOS adapters and physical qualification remain E4/F6/I15 work.
The native Windows path has also been reviewed against runtime
v11.0.0-rc.3.26522.148, commit 474ed963699fc29809015392738a15231aaae2de.
File.OpenHandle
still validates through the
shared helpers,
which accept the backup option.
SafeFileHandle.Open
forwards the option and maps FileAccess.ReadWrite to both native read and write access.
The operative
RandomAccess.FlushToDisk
is in the common implementation: it validates the handle without rejecting directories,
then calls the
Windows flush helper.
That helper still suppresses ERROR_ACCESS_DENIED; the
FlushFileBuffers import
still captures last-error state. The adapter’s immediate cleared/captured check
therefore remains necessary. This review establishes source correspondence for
the existing adapter, not runtime or physical-storage qualification. Focused
DirectoryPersistenceTests on the native .NET 11 asset must exercise writable
acknowledgements, suppressed read-only refusal and publication/ownership failures;
successful runtime checks still do not establish power-loss durability.
No OS/filesystem/device combination currently has a power-loss qualification receipt in this repository. Ordinary CI supplies runtime, parser and injected-fault evidence. A future receipt must identify the OS/kernel, exact runtime, filesystem/version and mount options, local or remote transport, virtualization layers, controller/device firmware and cache/power protection. A filesystem family name alone is insufficient.
For that fixed configuration, record the following evidence before promoting a storage guarantee:
The caller-stream recovery contract defines current stream classification, live rollback, disposal/failure ownership and exclusive-access obligations, together with the complete journal identity, discovery, fence, reopen, lease and evidence-retention capabilities required of a future persistent stream adapter. The current public stream overloads provide no persistent journal-stream API. A wrapper around a FileStream follows the custom-stream path; CanSeek, successful FlushAsync or an in-process semaphore cannot establish persistent recovery.
The library’s current file sidecars are library recovery evidence. Microsoft Access does not replay them; a native open after an interrupted library mutation must follow library recovery. Format interoperability and physical persistence remain separate acceptance requirements.