Repository navigation
Make an append to a missing file agree across providers when another writer creates it meanwhile #65
Description
An unconditional append (UpdateFileMode.Append, no conditions) to a missing file that another writer creates at the same moment ends differently by provider:
- Physical and the append-by-rewrite providers (S3, MinIO, GCS, Box, SharePoint) refuse with a create-only failure (
FileAlreadyExistsExceptionfrom 2027.1). - Azure Blob re-reads and appends after the new content, as it does after any concurrent change (
AzureBlobProviderTests.Races.cs,Append_CreatingRacesWithAnotherCreator).
Both keep the other writer's content, so nothing is lost, but the outcome differs, against "one meaning across providers". Making them agree changes what some provider does today, so it needs a decision: either the refusing providers retry and append after the new content (closer to what an append means), or Azure refuses.
Found in the plan review of #64 (P1) and left out of 2027.1 on purpose; docs/guide/providers.md records the difference until then.
Activity
serionist commentedon Oct 13, 2026
One-way door: the maintainers' agreement. @serionist approved this change in the 2027.1.1 plan (
docs/plans/2026-10-13-2027-1-1.md, decisions D1 and D2, approved 2026-10-13):PreconditionFailedException. A caller's ownIfMatchorIfNotExistsstill fails at once.AppendByRewriteAsync, a protected helper ofWriteableFileProvider<TOptions>and so part of the Common API, keeps its signature and its promise (a concurrent write is never lost); it now retries where it threw at the first conflict. This is read as a fix toward one meaning across providers, the rule this difference broke, and ships as a patch, 2027.1.1.Read past a lost create only once the other writer's file has content
Keep Windows reading past a lost create, and name Physical's corner w…
Pin the Windows read-past with an empty winner, and give the corner o…
Word the corner's reason the same way in the exception's docs and the…
Retry an unconditional append after a concurrent change on every prov…
Date the 2027.1.1 changelog for the release
serionist commentedon Oct 13, 2026
Shipped in 2027.1.1 (nuget.org, every package), through #74: an append with no condition now reads the file again after a concurrent change or create and appends after it, on every provider, up to five attempts. One corner stays as it was, documented: on Linux and macOS, Physical's append that loses a new name throws
FileAlreadyExistsExceptionwhile the file there is still empty.