4.6 KiB
Transcript file sharing diagnostic
Purpose: distinguish a writer error from a completed write when a reader with the original test's access mode remains open. This temporary diagnostic does not change the app, its tests, or their 577-case count.
Entry point: tools/ci/TranscriptFileShareProbe.cs, a .NET 10 file-based app with BCL-only dependencies. From this clone:
/Users/dh/.dotnet/dotnet run --file tools/ci/TranscriptFileShareProbe.cs
On another machine use its .NET 10 SDK executable. The file-based app requires an SDK supporting file-based apps; the prepared local run uses SDK 10.0.401. Native AOT is disabled for this diagnostic so its JSON report can use the normal reflection serializer. It prints JSON with runtime/OS, write completion, exception type/HResult/native error code, content after reader disposal, and cleanup status. It creates a unique directory beneath the system temporary directory, writes two small fixture files, and deletes only that directory in finally. It starts no Meeting Assistant app, service, network client, container, or VM. The SDK can create its normal file-based build cache. For a fresh CLI profile set DOTNET_GENERATE_ASPNET_CERTIFICATE=false and DOTNET_CLI_TELEMETRY_OPTOUT=1 to disable unrelated certificate/telemetry initialization.
The optional instrumentation in the existing recording-coordinator test observes public provider and transcript-store boundaries: audio consumed, fake segment yielded, append/rewrite entered, completed, or failed. Timeout output uses [DEBUG-transcript-write-4174] and includes elapsed milliseconds, exception type, HResult, and message. The reader, 15-second wait and final redaction assertions are unchanged. StopAsync always runs in finally; a stop failure does not mask the original timeout. Timestamps distinguish events before and after the failed wait. Instrumentation can affect race timing; a passing run alone does not explain the original failure. This temporary instrumentation should be removed after the actual Wine incident is explained.
The original-reader case uses the same path-taking StreamReader constructor as File.ReadAllText. It deliberately holds the reader after reading the fixture so that the overlap is deterministic. The original test normally disposes that reader immediately after ReadToEnd; therefore this probe checks compatible access modes, not the historical race's timing. The second write happens after disposing that reader. The compatible case holds FileAccess.Read with FileShare.ReadWrite | FileShare.Delete. No reader fix is applied to the actual test.
The existing Wine job runs this probe after its actual Windows SDK build and before the unchanged full test cohort. It writes artifacts/tests/transcript-file-sharing.json and prints that report into the CI log. Invocation there uses the already installed Windows SDK through the existing WINE_BIN; no runner or infrastructure capability is added. The measured Wine result is pending until this exact workflow executes.
Primary-source contract
In .NET runtime v10.0.12 File.cs, ReadAllText constructs a path-taking StreamReader; StreamReader.cs opens read access sharing only further readers. WriteAllTextAsync delegates to a create-mode write; its writer opens write access with reader sharing.
Windows CreateFileW documentation requires existing access and sharing modes to remain compatible until handle closure. A held reader that does not permit writes therefore prevents that writer from opening; the Windows contract expects an IOException with sharing-violation native code 32. Allowing read/write sharing removes that incompatibility. Delete sharing is included for the comparison but this probe does not rename or delete an open file.
On Windows the CLI asserts that the original held-reader write fails with code 32 and leaves the original bytes, and that both subsequent writes complete with the expected content. On other platforms it reports the original-reader observation without asserting Windows behavior (WindowsContractMatched: null), and still checks completed compatible/released writes and cleanup. The Unix/macOS implementation can differ. A local macOS success is not evidence of Wine behavior or the cause of Run4174's timeout.