---
id: "20261031-0235-is-the-2026-07"
title: "Is the 2026-07-07 04:05 uncommanded-deletion anomaly a named failure mode, and does the literature prefer a standard fix over 'revert forward and flag it'?"
type: "capture"
status: "promoted"
promoted_to: ["30-notes/claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing.md","30-notes/claim-occ-kung-robinson-1981-detects-conflicts-after-the-fact.md","30-notes/claim-no-primary-source-prescribes-occ-event-sourcing-for-sweep-vs-write-toctou.md","50-questions/question-does-literature-prescribe-occ-or-event-sourcing-for-sweep-vs-write-toctou.md","40-entities/entity-optimistic-concurrency-control.md (new concept hub)","40-entities/entity-h-t-kung.md (updated — appended 1981 OCC co-authorship fact)"]
not_promoted: ["John T. Robinson (entity candidate) — co-authorship on the 1981 OCC paper alone, no separate standing sourced in-vault; per the 2026-10-01 Cali ruling this is a mention, not a hub. Named in both new claim-notes and the OCC entity hub as co-author.","MITRE Corporation / CWE (entity candidate) — load-bearing for two clusters now (this capture and claim-cve-2025-38352), but CWE is a passive classification taxonomy, not an org that funds/builds/decides/blocks; fails the stricter org-promotion bar. Mention only.","Forward recovery / backward recovery vocabulary (further lead) — contested among Tier 3-4 sources (USPTO patents, a Univ. of Malta thesis, Helsinki/Aalborg course slides), not load-bearing for any kept claim this promotion, and not recurring elsewhere in the vault. Needs a primary (Gray & Reuter, Transaction Processing) before it can anchor a claim or earn an entity stub. Left in this capture's body as a lead, not routed to a question since no kept claim rests on it.","Tsafrir, Hertz, Wagner & Da Silva 2008 USENIX FAST TOCTOU-hardening paper (further lead) — not yet read; folded into the routed question's candidate next moves rather than given its own claim or question.","Remote-attestation TOCTOU sub-literature (arXiv, surfaced by search, not fetched) — a different sub-literature from the file/database TOCTOU this capture covered; left as a lead in this capture's body, no claim or question warranted yet.","CWE-367's 'Research Gap' note on non-symlink TOCTOU being under-reported (further lead) — an observation about the field's literature, not a claim this vault can verify or act on; left in this capture's body.","2024 arXiv preprint on DBMS data-anomaly classification (further lead) — not read; a candidate stronger primary than Berenson 1995 for a future session, not promoted now."]
origin: "batch"
writer_model: "claude-sonnet-5"
date_created: "2026-10-31T00:00:00.000Z"
provenance: "batch run, 2026-10-31"
derived_from: []
tags: ["concurrent-systems","race-conditions","toctou","lost-update","optimistic-concurrency-control","cwe","concurrency-control-history"]
source_url: "https://cwe.mitre.org/data/definitions/367.html"
source_title: "CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition"
source_author: "MITRE Corporation / CWE Content Team"
source_date: "2026-10-28 (CWE 5.0 revision; entry established 2006)"
source_venue: "Common Weakness Enumeration (CWE), sponsored by DHS CISA"
source_tier: 1
source_sha: "a39970c0d78b30307c4efc90bbf1db9faeb91ae31ce35e427c9bbf829be32611"
seek_code_commit: "d40ee39"
---


The hook: on 2026-07-07 at 04:05, a periodic timer swept up and deleted
content that a foreground write was still in the process of committing
(the anomaly introduced in commit `bd2f51a`, reverted in `7deae5b`). The
question is whether concurrent/distributed-systems literature already has
a name for "a background sweep races an in-flight foreground write," and
whether that literature prescribes a standard fix — optimistic locking,
event sourcing — that would have handled the incident better than the
practitioner response actually taken (revert forward and flag it).

Three primary sources were read directly for this capture: MITRE's own
CWE-367 and CWE-362 weakness-taxonomy pages (archived, sha recorded above
and below), and Kung & Robinson's 1981 ACM TODS paper "On Optimistic
Methods for Concurrency Control" (fetched from the authors' own
eecs.harvard.edu hosting). All three resolved cleanly over verified TLS.

## Claim: The anomaly's shape is a named, formally classified failure mode — CWE-367 (TOCTOU), child of CWE-362 — and that classification's own stated mitigations are atomicity and locking, not optimistic concurrency or event sourcing

MITRE's CWE-367 defines the weakness class directly: "The product checks
the state of a resource before using that resource, but the resource's
state can change between the check and the use in a way that invalidates
the results of the check." A timer that sweeps based on a check of
resource state (e.g., "this write looks stale/orphaned, safe to delete")
racing a foreground write that is still committing is a textbook instance
of this shape: check (the sweep's staleness test) and use (the delete)
are separated by a window the foreground write can fall into. This is the
same class the vault has already anchored to a concrete, in-the-wild
instance via [[claim-cve-2025-38352-timer-sweep-toctou]] (a Linux kernel
POSIX-CPU-timer sweep racing a concurrent deletion, CWE-367, CISA KEV).

Critically, CWE-367's own "Potential Mitigations" section — read in full,
not excerpted by a summarizer — lists exactly six remedies, and none of
them is optimistic locking or event sourcing: don't check before use at
all; limit interleaving of operations across processes; shrink the
check-to-use time window when atomicity isn't possible; recheck the
resource after use; use an "environmental locking mechanism"; and,
explicitly, "Ensure that locking occurs before the check, as opposed to
afterwards, such that the resource, as checked, is the same as it is when
in use." The parent class CWE-362 ("Concurrent Execution using Shared
Resource with Improper Synchronization") likewise lists only
synchronization primitives, mutexes, atomic operations, and
least-privilege as mitigations — again, no mention of optimistic
concurrency control or event sourcing anywhere on either page.

source_url: "https://cwe.mitre.org/data/definitions/367.html"
source_title: "CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition"
source_author: "MITRE Corporation / CWE Content Team"
source_date: "2026-10-28"
source_venue: "Common Weakness Enumeration (CWE), DHS CISA-sponsored"
source_tier: 1
source_sha: a39970c0d78b30307c4efc90bbf1db9faeb91ae31ce35e427c9bbf829be32611
source_quote: "The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check."
source_quote_2: "Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use."

source_url_2: "https://cwe.mitre.org/data/definitions/362.html"
source_title_2: "CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization"
source_author_2: "MITRE Corporation / CWE Content Team"
source_date_2: "2026-10-28"
source_venue_2: "Common Weakness Enumeration (CWE), DHS CISA-sponsored"
source_tier_2: 1
source_sha_2: 45eb73f07c50ebbe86d3b0b742eb1a6efcc42d4b5737deeb610d68dc86876070
source_quote_3: "Use atomic operations on shared variables."

## Claim: Optimistic locking's actual ancestor is "optimistic concurrency control" (Kung & Robinson, 1981), a database-transaction technique that detects a conflicting concurrent write *after the fact* and responds by aborting and restarting the losing transaction — not by preventing the race up front

H.T. Kung and John T. Robinson's 1981 ACM Transactions on Database
Systems paper "On Optimistic Methods for Concurrency Control" is the
foundational source for what is colloquially called "optimistic locking"
today. The paper proposes concurrency control built on a read phase, a
validation phase, and a write phase, in which "all writes take place on
local copies of the nodes to be modified" during the read phase, and a
global commit only happens if validation at the end detects no
conflicting concurrent transaction. The paper's own framing: "The methods
used are 'optimistic' in the sense that they rely mainly on transaction
backup as a control mechanism, 'hoping' that conflicts between
transactions will not occur." When validation fails, the fix is not
silent repair — "If validation does fail, the transaction will be backed
up and start over again as a new transaction." The paper's own conclusion
section is explicit that this is one of exactly two control mechanisms
practice relies on — "locking and backup" — and frames optimistic methods
as orthogonal to locking, trading wait-and-block for detect-and-restart.

This matters for the anomaly: optimistic concurrency control (OCC) is the
database-transaction-theory answer to the *lost-update* shape (the vault's
[[claim-lost-update-p4-distinct-from-toctou]] already establishes lost
update/P4 as a separate 20th-century naming tradition from TOCTOU), and
it is a detect-after-the-fact, abort-and-retry discipline — structurally
closer to "notice the clobber, then correct it" than to a pre-emptive
lock. The 2026-07-07 incident's actual response (revert forward and flag)
is, in that light, the manual analogue of OCC's "backed up and start over"
step, just performed by a human after the fact rather than by a validation
routine before the write was ever allowed to appear to succeed.

source_url: "https://www.eecs.harvard.edu/~htk/publication/1981-tods-kung-robinson.pdf"
source_title: "On Optimistic Methods for Concurrency Control"
source_author: "H.T. Kung and John T. Robinson"
source_date: "1981-06 (ACM Transactions on Database Systems, Vol. 6, No. 2, pp. 213-226)"
source_venue: "ACM Transactions on Database Systems"
source_tier: 1
source_sha: 5bd2f2e7b2356de972e7e6bd19ebc229568dd7968bc01acc3583038003ce364e
source_quote: "The methods used are \"optimistic\" in the sense that they rely mainly on transaction backup as a control mechanism, \"hoping\" that conflicts between transactions will not occur."
source_quote_2: "If validation does fail, the transaction will be backed up and start over again as a new transaction."
source_delight: "The paper that gave 'optimistic locking' its name is a 14-page ACM TODS paper still hosted free on its own author's Harvard faculty page, forty-five years on."

## Claim: No primary source found recommends optimistic concurrency control or event sourcing specifically as the standard fix for a timer-sweep-vs-foreground-write race — the TOCTOU tradition's own literature prescribes atomicity/locking instead, so the premise that OCC or event sourcing is literature's "standard fix" for this exact shape is unverified

The core question asks whether concurrent-systems literature suggests a
standard fix — "optimistic locking, event sourcing" — better than "revert
forward and flag it." Having read CWE-367 and CWE-362 (the formal
taxonomy for this exact check-then-act shape) in full, their own
"Potential Mitigations" sections prescribe atomicity, synchronization
primitives, and lock-before-check — never optimistic concurrency control
and never event sourcing. Optimistic concurrency control is real,
foundational, and well-documented (Claim 2 above), but it answers a
different question — how to let concurrent transactions proceed without
blocking, catching conflicts at commit time — not the specific
sweep-vs.-write TOCTOU shape, for which the field's own literature
reaches for locking and atomicity instead. A general web search for
"event sourcing" as a fix for lost-update/sweep races turned up only
secondary commentary (a DEV Community post, a Confluent engineering blog)
arguing that append-only logs do not by themselves prevent a lost update
without an added optimistic-concurrency check on the stream's expected
version — none of which clears the Tier 1-2 floor for a technical-
mechanism claim, and none of which is a primary source actually
recommending event sourcing for this failure shape.

**This is a case of "could not fully confirm or deny" rather than a
clean answer.** It is confirmed that the anomaly's shape is a named,
formally classified failure mode (CWE-367/362, a crisp "yes" to the first
half of the question). It is **not confirmed** that the literature
converges on optimistic locking or event sourcing as *the* standard fix
for this particular shape, better than revert-and-flag — the one body of
literature that formally classifies this exact shape (CWE) prescribes
something else (atomicity/locking), and the literature that does
champion optimistic concurrency control is answering a related but
distinct problem (lost update in transaction processing, per
[[claim-lost-update-p4-distinct-from-toctou]]). The second half of the
topic question is marked `[unverified -- could not confirm or deny after search]`.

> [!note] Seek's commentary: The honest finding here is a mismatch, not a
> verdict. The question bundles two traditions ("optimistic locking,
> event sourcing") as if concurrent-systems literature treats them as
> interchangeable upgrades over "revert and flag" for *any* check-then-act
> race. Reading the TOCTOU taxonomy's own mitigations directly shows that
> its field reaches for locking and atomicity, not OCC — which is the
> database-transactions field's answer to a sibling problem. The
> interesting result is that "revert forward and flag it" isn't a lesser
> cousin of OCC; it's structurally the same move (detect after the fact,
> back up and redo) that Kung & Robinson treat as one of exactly two
> legitimate concurrency-control mechanisms, just performed by a human
> instead of a validation routine. Whether a *pre-emptive* fix (locking
> the sweep's check against the write, per CWE-367's own advice) would
> have been better than a *reactive* one (revert and flag) is a real,
> answerable engineering question — but it's an architecture question for
> whoever owns the timer, not something "the literature" settles in the
> abstract. — Seek

## Further leads

- Forward-recovery vs. backward-recovery vocabulary (fault-tolerant/transactional-systems literature: a repair that "undoes" state vs. one that "repairs forward and keeps going") may be the better conceptual match for "revert forward and flag it" than OCC is — but the sources found (USPTO patents, a Univ. of Malta thesis chapter, Helsinki/Aalborg course slides) are Tier 3-4 and the terminology itself is contested among them ("one paper argues a compensation is conceptually backward recovery... another suggests backward error recovery as a particular form of forward recovery"); needs a primary textbook source (e.g., Gray & Reuter, *Transaction Processing: Concepts and Techniques*) before this can anchor a claim. [unverified-mechanism — needs primary]
- Dan Tsafrir, Tomer Hertz, David Wagner, Dilma Da Silva, "Portably Solving File TOCTTOU Races with Hardness Amplification" (USENIX FAST 2008) is cited directly in CWE-367's own references [REF-367] as prior TOCTOU-mitigation research — not yet read, but a primary candidate for a deeper mitigation-techniques note.
- "On the TOCTOU Problem in Remote Attestation" (arXiv, surfaced by search but not fetched this session) discusses TOCTOU mitigation in a specialized remote-attestation context (randomized block-order schemes like SMARM) — a different sub-literature from the file/database TOCTOU this capture covered.
- CWE-367's "Research Gap" note states plainly: "Non-symlink TOCTOU issues are not reported frequently, but they are likely to occur in code that attempts to be secure" — worth flagging as a standing gap given the vault's own kernel-timer and (per this capture) agent-tooling instances are both non-symlink TOCTOU.
- A 2024 arXiv preprint, "Systematic definition and classification of data anomalies in DBMS," surfaced by search — not read — could be a stronger primary source than the existing Berenson 1995 paper for how modern database theory classifies lost-update-adjacent anomalies; worth a follow-up fetch.

## Entity candidates

- H.T. Kung — person — co-author of the 1981 optimistic-concurrency-control paper; the field's foundational figure for "optimistic locking," and the one this whole tradition's priority rests on (ask-first per the known blind spot: the ancestor, not the citing paper).
- John T. Robinson — person — co-author of the same 1981 paper; equal billing with Kung on the OCC foundation.
- MITRE Corporation / CWE — concept/org — maintains the CWE-362/367 taxonomy that is the closest thing to an authoritative "standard fix" registry for this failure shape; already load-bearing for [[claim-cve-2025-38352-timer-sweep-toctou]], now load-bearing here too.
- Optimistic concurrency control (OCC) — concept — the formal name behind "optimistic locking"; distinct from, but routinely conflated with, TOCTOU mitigation.
- Forward recovery / backward recovery — concept — contested fault-tolerant-systems vocabulary that may be the more precise academic category for "revert forward and flag it" than OCC is; flagged above as needing a primary source.