Derive a file's flush domains at its open (M39)

.github/workflows/ci.yml

@@ -392,7 +392,7 @@ jobs:
         env:
           RUST_BACKTRACE: 1
           RUST_LIB_BACKTRACE: 1
-        run: cargo test -p win-durable-ioring --locked --lib -- --include-ignored an_unbuffered_file_is_refused_on_a_remote_device
+        run: cargo test -p win-durable-ioring --locked --lib -- --include-ignored an_unbuffered_file_is_refused_on_a_remote_device a_file_on_a_share_has_no_domains_found
       # A raw volume against a real one: a scratch virtual disk, created and attached with diskpart,
       # which the runner's administrator account can do and a developer's usually cannot (DI-D-61).
       # Nothing here is real storage; each test detaches and deletes its own disk. A failure here is
@@ -406,7 +406,7 @@ jobs:
         env:
           RUST_BACKTRACE: 1
           RUST_LIB_BACKTRACE: 1
-        run: cargo test -p win-durable-ioring --locked --lib -- --include-ignored raw_volume raw_disk
+        run: cargo test -p win-durable-ioring --locked --lib -- --include-ignored raw_volume raw_disk a_file_on_a_virtual_disk
       # The ETW provider wrapper against real trace sessions (WE-D-3): each test starts a session
       # that logs to a file, enables a provider in it, and reads the file back. Starting a session
       # needs an elevated process or the Performance Log Users group, which the runner's

CHECKLIST.md

@@ -490,79 +490,6 @@ Historical means `COMPLETED-*` archives, `design-sessions/`, measurement capture
   and the root [DESIGN-NOTES.md](DESIGN-NOTES.md). Commit as `docs`, one commit per crate so each
   scope stays accurate.
 
-## M39 -- A file's flush domains, derived when it is opened through the namespace route
-
-Opened 2026-10-06 from the durable-ioring design session
-([DESIGN-SESSION-2026-10-05-epoch-ring.md](design-sessions/DESIGN-SESSION-2026-10-05-epoch-ring.md)) as a free-standing
-locality helper; **re-scoped 2026-11-05** by the engineer. durable-ioring takes, per file, a set of opaque
-**flush-domain** keys ([DI-D-21](crates/durable-ioring/DESIGN-NOTES.md#di-d-21)) and never looks at Windows' storage
-stack itself. Everything that consumes the keys is built: declarations, failure import, and the routing provider
-([DI-12.2](crates/durable-ioring/COMPLETED-CHECKLIST.md#di-122)). `win-durable-ioring` already derives them for a raw
-volume or disk from its extents, as `disk_flush_domain` ([DI-D-61](crates/durable-ioring/DESIGN-NOTES.md#di-d-61)); for a
-file it derives none, and its documentation says a file's domains "are what it cannot know", so a consumer declares them
-with `with_domains`.
-
-**The scope, in the engineer's words (2026-11-05):** "this isn't saying that durable ioring only supports this but that
-our assistance for computing domains comes when you use the namespace crate. This way we have the namespace available to
-use namespace based OS functions as well as the handle based ones. Advanced users who want to hand handles to the durable
-ioring directly, I will assume are advanced enough to also manage their domains directly." So the derivation belongs to
-`win-durable-ioring`'s open, which goes through `windows-namespace-request-sys`' `OpenFile` and has both the name and the
-handle in `OpenRequest::perform`; a target made any other way declares its own, as today. That settles the old `M39.1`
-(where the helper lives) and drops its facts-or-policy question: the policy is `win-durable-ioring`'s, as it is for a raw
-volume, and each OS call stays one entry in the namespace or volume crate.
-
-The keys are the identifier's **exact bytes**, interned by dioring (the engineer, 2026-10-06, under
-[DI-2.10](crates/durable-ioring/COMPLETED-CHECKLIST.md)); a file's local keys are the same `disk_flush_domain` bytes a
-raw volume derives, so a file and a volume on one disk share fate by construction.
-
-- [ ] **M39.1** -- **Record the decision, and settle its two open choices.** A decision in durable-ioring's
-  [DESIGN-NOTES.md](crates/durable-ioring/DESIGN-NOTES.md), amending what `win-durable-ioring` says a file can know and
-  what [API.md](crates/durable-ioring/API.md) section 13 says ("a locality helper's job outside this crate"), with the
-  engineer's ruling quoted. The choices: whether a file's domains are derived at the open (every open pays for a few
-  queries, one of them on the volume) or on first request; and whether an open by identifier (`OpenFileById`), which has
-  a hint handle and no name, gets the handle-based half or none.
-
-- [ ] **M39.2** -- **Derive a file's found domains at its open, all or nothing.**
-
-  - [ ] **M39.2.1** -- **Wrap the name-based calls the derivation needs**, as entries in
-    `windows-namespace-request-sys`, which exists for synchronous namespace calls that can block on the network. Check
-    each against its page first and record which were checked. Candidates, none yet confirmed for this use:
-    `DfsGetClientInfo` (a DFS link to the target it is using), `GetDriveTypeW` (a removable or RAM disk, which no
-    handle-based documented call reports), and `GetVolumePathNameW` with `GetVolumeNameForVolumeMountPointW` (the volume a
-    name resolves to, for the prediction of `M39.3`). Anything the handle answers is asked of the handle.
-
-  - [ ] **M39.2.2** -- **A local file's domains.** The handle's final path in `VOLUME_NAME_GUID` form names its
-    volume; the volume, opened with no access as `win-volume-sys`' tests do, gives its disk extents; each disk is
-    `disk_flush_domain`. A disk that is a virtual disk is followed through its storage dependency to the volume holding
-    its backing file, and on from there. No real dependency entry has been observed yet, because attaching a virtual disk
-    needs an elevated token ([WV-D-10](crates/win-volume-sys/DESIGN-NOTES.md#wv-d-10)), so that hop's test needs a
-    privileged run or a stated gap.
-
-  - [ ] **M39.2.3** -- **A remote file's domain.** The server, from the handle's final path, which the open already reads
-    to refuse a remote device for an unbuffered file and which follows mapped drives and links; a DFS link resolved
-    through its name. Keyed by server and not by share, since two shares on one server sit on disks this cannot see and
-    the coarser key is the safe one.
-
-  - [ ] **M39.2.4** -- **All or nothing, and what is left to the consumer.** Any hop that fails leaves the file with no
-    found domains, which is unknown and shares fate with everything: the safe default, never a partial set, which is the
-    one way a declaration makes the contract false. `with_domains` stays, adding what Windows does not show, and its
-    documentation names it: the disks of a Storage Spaces pool (reachable only through the Storage Management API's WMI
-    classes), the disks behind a hardware RAID controller, and a cache a controller shares between disks.
-
-- [ ] **M39.3** -- **Predict a directory's domains before a file is created, and confirm them at the open.** A consumer
-  presents storage roots as directories and wants to know, before creating files, where they will land: the
-  directory's volume, mount points included, through the name-based calls of `M39.2.1`. Its path is resolved again at
-  each create, so a junction swapped between the two sends the file elsewhere; the open's own derivation is what the
-  file's declaration uses, so a swap cannot make it wrong, and the prediction is compared with it and a mismatch
-  reported. An open relative to the directory's handle would close the race, and is parked as
-  [DI-15.3](crates/durable-ioring/PARKED.md) for want of a documented call. From
-  [the design session](design-sessions/DESIGN-SESSION-2026-10-21-router-domains-and-paired-events.md#the-real-world-model);
-  the engineer, 2026-10-21: "The volume id refinement is a good catch for that race condition."
-
-- [ ] **M39.4** -- **Show it end to end, in the shape of the working model:** a data directory and a log on separate
-  disks, files opened through the namespace route with their domains derived, and a failed flush on one shown not to
-  make the other's writes suspect. Coarse on purpose: whether that can be shown without hardware that fails on demand is
-  settled once `M39.2` is built.
 ## M42 -- Apply the documented-contract rule to the refusals that already exist
 
 The rule is in [DESIGN-NOTES.md](DESIGN-NOTES.md#refusals-rest-on-the-documented-contract) (the engineer,