[Olof-Lagerkvist]

Summary

Consolidates the original NTFS $LogFile recovery work from #87 with the subsequent safety and durability fixes in #88–#92 and #94–#96. The result adds supported NTFS journal analysis and recovery, a storage-independent SparseStream.Flush(bool) contract, and iSCSI cache synchronization through that contract.

This PR targets LTRData.DiscUtils-initial from review/pr-87-base. It supersedes the original #87 implementation as reviewed; #93 is not included because its hibernation checks were largely superseded by #91.

NTFS journal behavior

• NtfsJournal.Analyze(Stream) inspects $LogFile and reports Clean, NothingToReplay, NeedsReplay or Unsupported without writing.
• Default writable open is conservative: new NtfsFileSystem(stream) refuses an unclean journal that needs replay or reset, and refuses unsupported journals. It does not silently replay on a writable open.
• Default read-only open applies supported redo/undo to an in-memory overlay without changing the backing volume. If replay is unsupported, the volume is exposed without recovery and callers can inspect JournalInfo.Status.
• NtfsJournalMode.Replay or NtfsJournal.Replay(stream) explicitly opts into persistent recovery on a writable stream when supported. The Refuse and Ignore modes and the per-open FileSystemParameters.Parameters["NtfsJournalMode"] entry are also available.
• The journal is analyzed before the filesystem is mounted. Validated recovery handles log/restart pages, redo, supported in-memory undo and metadata changes, including updates to $MFTMirr.

Recovery safety

The follow-up PRs strengthen validation of LFS client identity, transaction/undo chains, page mappings, damaged or torn pages, overlapping changes and restart-page agreement. Unresolved metadata undo is not persisted: without restartable logged compensation records, the persistent path refuses it before writing. In-memory bitmap undo supports disjoint bit runs from different transactions.

Recovery refuses active or indeterminate local hibernation/Fast Startup evidence, inspecting both the original volume and the staged replay result. This is not proof of exclusive ownership: a suspended Windows installation may still own a data volume whose resume image is elsewhere.

Persistent replay writes and flushes in this order:

1. Relevant $MFTMirr records.
2. Primary metadata.
3. Alternate restart page.
4. Former source restart page.

The pre-reset metadata barrier is requested even when the current attempt has no metadata changes, covering buffered bytes from an earlier interrupted attempt. Partial reset recognition and retry checks refuse inconsistent recovery states instead of continuing to write.

Extensible storage flushes

SparseStream now has virtual Flush(bool flushToDisk), defaulting to Flush(). Built-in wrappers forward the request, SparseWrapperStream passes it to FileStream.Flush(bool) when appropriate, and VHD/VHDX content streams forward it to their backing streams. NTFS invokes Flush(true) through a non-owning sparse adapter; it does not search for a nested FileStream.

iSCSI DiskStream.Flush(), Flush(true) and FlushAsync() now send full-LUN SCSI SYNCHRONIZE CACHE (10) with IMMED=0, unconditionally, and propagate explicit synchronization failures. The iSCSI package README documents target-dependent guarantees.

Validation

• Five retained Windows crash-image fixtures compare the supported replay result with Windows-recovered metadata. The original NTFS: read and replay the $LogFile journal (analysis, redo, undo) #87 reports additional manual crash comparisons.
• Synthetic tests cover supported/unsupported operations, hibernation decisions, LFS client checks, disjoint bitmap undo, torn writes, flush failures, exact persisted bytes at interruption points and subsequent retries.
• Tests verify Flush(true) dispatch through file/partition/sparse wrappers and the iSCSI synchronization CDB.
• Latest code-change CI: Windows Server 2025, Ubuntu 24.04 and macOS 15 all passed. README-only updates on this branch should receive their own CI checks.

Boundaries and remaining work

• Recovery is not atomic. Success requires the supplied stream, filesystem, runtime and physical/remote storage to honor write ordering and flush semantics. The durability notes document a Linux .NET 10 fsync error-reporting limitation and cases no replay protocol can detect if a backend acknowledges lost writes.
• Persistent recovery requiring metadata undo is intentionally unsupported pending independent Windows and compensation-record qualification. See undo and interruption qualification.
• Local hibernation checks cannot detect a suspended operating system whose resume file is on another volume. The caller must establish offline, exclusive ownership. See hibernation notes.
• Backend-specific power-loss behavior, container allocation updates and live iSCSI target failure scenarios need separate qualification. An unsupported journal on a read-only open can still expose stale metadata; check JournalInfo.

The NTFS package README, Streams package README and repository overview now summarize the behavior and limitations.

Review focus: conservative writable-open defaults, limits of persistent undo, interruption/retry ordering, and whether the documented storage guarantees are appropriate for downstream consumers. Please review and merge manually; no automatic merge requested.