| Previous | Next |
| STATUS_LOG_INCONSISTENT_SECURITY | STATUS_LOG_PINNED_RESERVATION |
STATUS_LOG_APPENDED_FLUSH_FAILED
STATUS_LOG_APPENDED_FLUSH_FAILED is especially important because it says records were appended or reservation changes were made before the log could not be flushed. The caller must therefore use its own idempotency and recovery rules instead of assuming a clean all-or-nothing application outcome.
This is a durability boundary. CLFS exposes flush operations for marshalling buffers and LSN ranges; an earlier in-memory or append-stage success is not a substitute for confirming the required stable-storage state.
What to inspect
- Record the highest requested LSN, flush boundary, reservation deltas, and underlying storage error before retrying.
- On restart, read and validate the log according to the client recovery protocol before deciding whether the logical operation must be replayed.
- Keep this result separate from a container-write failure: here the diagnostic question is what became durable, not simply whether a write call was issued.
References
- Microsoft: ClfsMgmtHandleLogFileFull and full-log handling
- Microsoft: CLFS containers, tail pinning, and managed clients
- Microsoft: container, reservation, append, and flush APIs
- Wine: independent NTSTATUS constant definitions
Looking for a different code? Search another status or error code.