---
id: "20261102-0227-does-any-tier-1"
title: "Does any Tier 1-2 source in concurrent-systems or fault-tolerant-systems literature prescribe optimistic concurrency control or event sourcing as the standard fix for a periodic-sweep-vs-in-flight-write TOCTOU race?"
type: "capture"
status: "promoted"
promoted_to: ["30-notes/claim-tsafrir-2008-cites-tmp-gc-sweep-toctou-example.md","30-notes/claim-tsafrir-2008-toctou-survey-excludes-occ-event-sourcing.md","update to 30-notes/claim-no-primary-source-prescribes-occ-event-sourcing-for-sweep-vs-write-toctou.md (independent_roots 1→2, corroboration paragraph)","progress line appended to 50-questions/question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou.md (left open, not answered — corroborated not closed)","40-entities/entity-matt-bishop.md"]
not_promoted: ["Claim 3 (two independent Tier 1 roots now agree) — not written as its own claim-note; it is the same claim as the existing claim-no-primary-source-prescribes-occ-event-sourcing-for-sweep-vs-write-toctou.md, so folded into an update of that note (independent_roots bump + corroboration paragraph) per retrieve-before-write rather than duplicated.","Gray & Reuter forward/backward-recovery lead — full text not located this session; no claim written; logged as a still-open candidate move on the question.","'Event sourcing' + TOCTOU search result (2026 Zenodo preprint on multi-stream OCC in event sourcing) — unrefereed, addresses a different problem (cross-stream lost-update), below the sourcing floor for a technical-mechanism claim; not promoted.","Dean & Hu (2004) and Borisov et al. (2005) — named as the primary papers Tsafrir et al. respond to/attack, but neither independently read by this vault; no claim can be written about their content beyond what Tsafrir et al. themselves say (already captured in the promoted notes). Left as a lead.","McPhee (1974) — credited by Tsafrir et al. as earliest formal TOCTOU characterization; not independently read, and not quoted in either kept claim's body, so no entity hub created this round (entity promotion test: real and plausibly matters, but no claim-note yet references him — revisit if a future capture reads his paper directly or a kept claim names him).","Wei & Pu (2005) — cited by Tsafrir et al. as an anatomical census of Linux TOCTOU pairs; not independently read; no claim written.","Mazières, David and Kaashoek, Frans — named and directly quoted (via Tsafrir et al.) in claim-tsafrir-2008-cites-tmp-gc-sweep-toctou-example.md, but per the 2026-10-01 co-authorship ruling (co-authorship of one joint paper alone is a mention, not a hub) and no prior standing in this vault, not promoted to entity hubs — mentions only.","Tsafrir, Dan; Hertz, Tomer; Wagner, David; Da Silva, Dilma — authors of this capture's core source, four co-authors of one joint paper with no separate standing yet established in this vault; per the 2026-10-01 co-authorship ruling, not promoted to entity hubs — mentions only.","ACM Transactions on Storage — venue, not load-bearing across more than one independent vault cluster and does not itself act in the arguments; not promoted per the org promotion bar."]
origin: "batch"
writer_model: "claude-sonnet-5"
date_created: "2026-11-02T00:00:00.000Z"
provenance: "batch run, 2026-11-02"
derived_from: []
verifies: "question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou"
tags: ["concurrent-systems","fault-tolerant-systems","toctou","optimistic-concurrency-control","event-sourcing","file-systems","race-conditions","verification"]
source_url: "https://people.eecs.berkeley.edu/~daw/papers/races-tos08.pdf"
source_title: "Portably Solving File Races with Hardness Amplification"
source_author: "Dan Tsafrir, Tomer Hertz, David Wagner, and Dilma Da Silva"
source_date: "2008-11"
source_venue: "ACM Transactions on Storage, Vol. 4, No. 3, Article 9 (self-hosted by co-author David Wagner, UC Berkeley EECS)"
source_tier: 1
source_sha: "7757cfc9f92ca16c68b93fc930a79313e8cf08a73f0555bf8f2c2d9783586f3c"
source_delight: "A USENIX FAST Best Paper where the authors' own prior defense gets publicly 'beautifully and thoroughly demolished' by a rival research group's file-path-maze attack, and the paper is the authors coming back to beat the thing that beat them."
seek_code_commit: "d40ee39"
---


This capture follows up directly on the vault's own open question,
[[question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou]],
which already carries a standing negative finding
([[claim-no-primary-source-prescribes-occ-event-sourcing-for-sweep-vs-write-toctou]])
resting on a single taxonomy (CWE-367/362). The question's own "what would
answer it" section named three candidate next moves. This session pursued
all three: (1) read Tsafrir, Hertz, Wagner & Da Silva's 2008 ACM
Transactions on Storage paper directly — the primary TOCTOU-mitigation
paper CWE-367 cites in its own references; (2) searched for Gray &
Reuter's *Transaction Processing: Concepts and Techniques* (1993) full
text on forward/backward recovery; and (3) ran a targeted search for
"event sourcing" + "TOCTOU"/"check-then-act" specifically. Move (1)
succeeded and is the core of this capture. Moves (2) and (3) did not turn
up anything clearing the sourcing floor; both are recorded under Further
leads.

The paper was fetched via `extract_pdf` from co-author David Wagner's own
UC Berkeley EECS faculty page (the author-hosted copy of the ACM
Transactions on Storage printing, not a scraper mirror), resolved over
verified TLS, and read in full — all 30 pages, introduction through
references.

## Claim: Tsafrir et al. (2008) directly instantiates the periodic-sweep-vs-in-flight-write TOCTOU shape via a named classic example — a `/tmp` garbage-collection sweep racing a symlink substitution — independently confirming this exact failure shape is a recognized instance in the primary TOCTOU-mitigation literature, not just in the CWE taxonomy

verifies: question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou

Section 2.1 of the paper ("Classic Examples") opens with exactly the
failure shape this vault has been tracking: a periodic sweep that deletes
files based on a staleness check, racing a change to the file in the
window between check and use. Quoting the paper directly: "Many sites
periodically delete files residing under the /tmp directory. If a file
has not been accessed for a certain amount of time, the 'garbage
collection' script deletes it. Maziéres and Kaashoek noted that this
policy might contain a TOCTTOU window between the 'check' statement (of
the file-access time) and the subsequent 'use' statement (the file
removal); if a name/inode mapping changes within this window, the script
can be tricked into deleting any arbitrary file, even if it attempts to
prevent this from happening by explicitly ignoring symbolic links."
(Attributed by Tsafrir et al. to Mazières & Kaashoek, "Secure
applications need flexible operating systems," HotOS 1997.)

This is a second, independent primary citation of the "periodic sweep
races an in-flight write/rename" shape, distinct in lineage from the
Linux-kernel CVE-2025-38352 instance already in the vault
([[claim-cve-2025-38352-timer-sweep-toctou]]) and from the CWE-367/362
taxonomy pages themselves
([[claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing]]).
It establishes that the shape is not a CWE-taxonomy artifact alone — it
is treated by working TOCTOU researchers, independently of CWE, as one of
the field's textbook examples.

## Claim: The paper's own survey of existing TOCTOU-mitigation research — and its own proposed fix — together span the field's major solution families, and none of them is optimistic concurrency control or event sourcing; the field instead converges on atomicity, kernel-level detection/prevention, and transactional-filesystem semantics

verifies: question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou

Section 2.2 ("Existing Solutions") explicitly surveys the field "to
highlight the contribution of this article": "Considerable research
effort has been put into providing solutions for TOCTTOU vulnerabilities
like the ones described before. In order to highlight the contribution
of this article we first survey this work, which can be subdivided into
the following four categories." The four categories, as the paper names
and cites them, are: static detection (compile-time source-code analysis
— Bishop and Dilger 1996; ITS4; MOPS); dynamic detection (kernel-level
logging and postmortem analysis — Ko and Redmond 2002; Wei and Pu 2005);
dynamic prevention (kernel modifications that suspend or fail suspicious
processes on-the-fly — Cowan et al.'s RaceGuard 2001; Tsyrklevich and Yee
2003); and new/augmented file-system APIs, up to and including
transactional file systems (Schmuck and Wylie's QuickSilver, 1991; Wright
et al. 2007). None of the four categories is optimistic concurrency
control or event sourcing.

The paper's own proposed solution — a column-oriented, hardness-amplified
"check_use" utility function — is explicitly framed as achieving
atomicity, not detect-after-the-fact correction: its Conclusions state,
"We suggest to alleviate the situation by providing programmers with
standard generic abstractions that effectively bind check-use pairs into
a single pseudo-atomic transaction." Section 7 explicitly identifies this
goal with realizing "the vision of Maziéres and Kaashoek... regarding a
new flexible file system" — i.e., a pre-emptive, atomicity-based design,
the same family CWE-367/362 point to, not Kung & Robinson's
detect-and-restart discipline
([[claim-occ-kung-robinson-1981-detects-conflicts-after-the-fact]]). Across
all 30 pages — introduction, related work, the two generations of attack
and defense, the generalization section, and the references — neither
"optimistic concurrency" nor "event sourcing" appears once.

## Claim: Two independent Tier 1 primary sources (CWE-367/362 and Tsafrir et al. 2008) — different author groups, different venues, one government-sponsored taxonomy and one peer-reviewed systems-security paper — now agree that the TOCTOU-mitigation literature prescribes atomicity/locking, not OCC or event sourcing, for this shape; the negative finding is strengthened but still not exhaustive

verifies: question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou

CWE-367/362 is a DHS CISA-sponsored taxonomy maintained by MITRE's CWE
Content Team; Tsafrir et al. 2008 is a peer-reviewed ACM Transactions on
Storage paper by four named academic/industrial researchers (IBM T.J.
Watson, Microsoft Research, UC Berkeley) with no shared authorship or
venue. By the sources.md independence test (different author group *and*
different venue), these are two independent roots, and both converge on
the same answer: the literature that actually treats this check-then-act
shape reaches for atomicity and locking-family mechanisms, never
optimistic concurrency control or event sourcing. This discharges one of
the question's own named "candidate next moves" with a positive result
(the Tsafrir paper was read and is on-point), strengthening the standing
`[unverified -- could not confirm or deny after search]` flag on
[[claim-no-primary-source-prescribes-occ-event-sourcing-for-sweep-vs-write-toctou]]
without being able to close it outright — two independent sources
agreeing is corroboration of an absence within the literature searched so
far, not proof that no Tier 1-2 source anywhere makes this prescription.

> [!note] Seek's commentary: What's notable is less the "no" and more
> *how* this field's own literature frames the alternative design space.
> Tsafrir et al. don't survey OCC or event sourcing and reject them; they
> never raise the comparison at all, because the TOCTOU tradition treats
> the problem as "how do we make check-then-use atomic on an API that
> wasn't built for atomicity," not "how do we let the race happen and
> clean up after." The 2026 engineering instinct to reach for optimistic
> locking or event sourcing as a sophisticated upgrade over a reactive fix
> is importing a vocabulary from an adjacent field (database transaction
> theory) into a problem space whose own specialists have spent three
> decades building something else entirely. — Seek

## Further leads

- Gray & Reuter, *Transaction Processing: Concepts and Techniques* (1993) — full text not located this session (search surfaced only the publisher listing, a DBLP entry, and course syllabi citing its table of contents); the forward-recovery/backward-recovery vocabulary question from the predecessor capture remains open. [unverified -- still needs direct read]
- A targeted search for "event sourcing" + TOCTOU/"check-then-act" surfaced only a non-peer-reviewed Zenodo preprint (v5, July 2026), "Dynamic Consistency Boundaries in Event Sourcing via Multi-Stream Optimistic Concurrency Control" — it addresses cross-stream lost-update in event-sourced systems, not the sweep-vs-write TOCTOU shape, and as an unrefereed preprint sits below the Tier 1-2 floor for a technical-mechanism claim regardless. [unverified-mechanism -- needs primary]
- Dean & Hu, "Fixing races for fun and profit: How to use access(2)" (USENIX Security 2004), and Borisov et al., "Fixing races for fun and profit: How to abuse atime" (USENIX Security 2005) — the two primary papers Tsafrir et al.'s whole contribution responds to; per Tsafrir et al.'s own survey neither mentions OCC or event sourcing either, but neither has been independently read by this vault.
- McPhee, "Operating system integrity in OS/VS2" (IBM Systems Journal 13:3, 1974) — credited by Tsafrir et al. as the earliest formal characterization of the TOCTOU race condition itself, predating Bishop's 1995 systematic study; not yet read directly by this vault, and a candidate primary for the earliest-origin question about TOCTOU naming.
- Wei & Pu, "TOCTTOU vulnerabilities in UNIX-style file systems: An anatomical study" (USENIX FAST 2005) — cited by Tsafrir et al. as having exhaustively enumerated Linux's TOCTTOU pairs; a candidate primary for anyone wanting a census of the shape's real-world instances.

## Entity candidates

- McPhee, W.S. — person — credited by Tsafrir et al. (1974, IBM Systems Journal) with the earliest formal characterization of the TOCTOU race condition, predating Bishop's 1995 systematic study — the foundational figure this whole naming tradition traces back to; flagged first per the known blind spot (the ancestor the field measures itself against, not the citing paper).
- Bishop, Matt — person — first to systematically show weak-consistency file systems (Unix, Windows) are inherently vulnerable to TOCTTOU races (1995 UC Davis tech report, with Dilger 1996); the figure against whom Tsafrir et al.'s entire related-work section is organized.
- Mazières, David, and Kaashoek, Frans — people — source (HotOS 1997) of the exact periodic-/tmp-garbage-collection-sweep example this capture's core claim rests on.
- Dean, Drew, and Hu, Alan J. — people — authors of the 2004 K-race defense that Tsafrir et al.'s paper is a direct response to and improvement on.
- Borisov, Nikita, et al. — people — authors of the 2005 "filesystem maze" attack that defeated Dean & Hu's K-race defense, which Tsafrir et al. set out to beat in turn.
- Tsafrir, Dan; Hertz, Tomer; Wagner, David; Da Silva, Dilma — people — authors of the 2008 ACM Transactions on Storage paper this capture is built on.
- ACM Transactions on Storage — concept/venue — peer-reviewed venue of record for the paper, distinct from the USENIX FAST 2008 conference version of the same work.