Environment: `windows/amd64`, Windows 11, `dev` at `4b00615d8efe5f0a3bbc9e3313e73afbdb5341eb`. Built natively with MSYS2 UCRT64 (gcc 16.2.0-4, binutils 2.47-3) and Go `go1.26.2` fetched by `GOTOOLCHAIN`. The EVM conformance corpus was present, so `preflight`'s precondition is satisfied. `make build`, `make build-randomx` and `make test-randomx` all pass there (`ok zycord/core/pow/randomx 112.9s`, and `zcd-randomx vectors` reports 152 passed). `make test` does not: **22 tests fail in 10 packages.** I re-ran every package in isolation, uncontended, and all 22 reproduce deterministically. They fall into four groups, and I have ordered them by how much I think they matter. ## 1. A file mode the tree relies on is inert on Windows Go maps a `FileMode` onto the single `FILE_ATTRIBUTE_READONLY` bit on Windows, so `0o600` — owner-write present — sets nothing at all. Access is then decided entirely by the DACL the file inherits from its parent directory. A 20-line probe on this machine: ``` os.WriteFile 0o600 -> Stat().Mode().Perm() = 0666 (-rw-rw-rw-) os.WriteFile 0o400 -> Stat().Mode().Perm() = 0444 (-r--r--r--) ``` There is no mode a Go program can pass that means "owner only" there. Six tests fail on this, and the one to look at first is not a leaf: | test | package | what the file is | |---|---|---| | `TestWriteFileAtomicPublishesAtTheRequestedMode` | `node/storage` | the shared atomic-write helper itself | | `TestTheLedgerFileIsReplacedWholeAndLeavesNoLitter` | `node/underwrite` | the credit ledger — "it records who prepaid what" | | `TestAPublishedStateLeavesNoLitter` | `cmd/zycordd` | the underwriting state file | | `TestAStartedNodeIsHandedATrustTokenAndAnAdoptedOneIsNot` | `wallet/localnode` | the RPC trust token | | `TestAFirstRunRecordsThePolicyWhenTheDataDirectoryDoesNotExistYet` | `update` | the update policy file | `node/storage.WriteFileAtomic` is the primitive the first three go through, and it does `CreateTemp` → `Write` → `tmp.Chmod(perm)` → `Sync` → `Rename`; the `Chmod` is the inert call. Two further `0o600` writers have no test asserting the mode, so they did not show up in this run: `node/p2p/peerstore.go:250` and `desktop/main.go:807`. Nothing in the tree compensates. There are twelve non-test `*_windows.go` files and every one addresses a different problem — `renameNoReplace` via `MoveFileEx`, syncdir, lock, truncate, exec, replace — and there is not one occurrence of `SetNamedSecurityInfo`, `SECURITY_ATTRIBUTES`, `windows.ACL`, `SetEntriesInAcl` or `DACL` anywhere in the `.go` files. Whether this is exploitable depends on where the file lands. On a single-user machine the inherited `%LOCALAPPDATA%` ACL usually does restrict it — but for reasons that have nothing to do with the mode the code asked for. On this machine, which has a second local account, `icacls` on `%APPDATA%` — the tree `os.UserConfigDir()` resolves to, and where the wallet's trust token is written — shows that second account holding inherited Full control. I am not proposing a fix here because the right one is a design question: explicit DACLs on Windows, or an explicit decision that the mode is advisory there and the tests should say so. ## 2. Two failures that are not about Windows at all | test | package | |---|---| | `TestEveryStateConstructionOutsideThePackageIsClassified` | `core/state` | | `TestTheClassificationRegistryHasNoStaleEntries` | `core/state` | ``` sparse_population_test.go:142: unregistered state.State construction at node/chain/store.go::OpenConfig ``` `sparse_population_test.go:108` registers `node/chain/store.go::OpenWith`, but the construction now lives in `OpenConfig` (`node/chain/store.go:156`), with `OpenWith` (line 141) delegating to it. This is a source scan with no OS-dependent step in it, so I expect it fails on Linux too and that `make ci` is currently red on `dev` for everyone. I have not run it on Linux and cannot confirm that half. ## 3. Resource lifetime: handles and deletes | test | package | observed | |---|---|---| | `TestAbortDeletesFilesTheTransactionCreated` | `node/blobs` | `file 1 survived the Abort that created it` | | `TestNoReaderEverSeesAnUnparseableState` | `cmd/zycordd` | `rename …\.underwrite.json.tmp-… …\underwrite.json: Access is denied.` | | `TestWriteFileAtomicPublishesANewFileRatherThanTruncating` | `node/storage` | `rename …: Access is denied.` | | `TestAFailedReorgCommitRecordsNoReorgEvent` (3 subtests) | `node/chain` | `TempDir RemoveAll cleanup: unlinkat …\blocks\blk00000.dat: The process cannot access the file because it is being used by another process.` | | `TestAFailedApplyCommitRecordsNoEpochOutcome` | `node/chain` | same | Windows refuses a rename over a file another handle still holds open, and refuses to unlink one. These read as handles outliving the operation that opened them rather than as test artefacts — the `node/blobs` one especially, since an `Abort` that leaves its files behind is a statement about the transaction, not about the platform. ## 4. Storage compaction, and three test-only assumptions Four `node/storage` failures look like genuine behaviour differences rather than assertions about the platform, and I do not understand them well enough to characterise them: ``` TestAttack2GroupTriggersItsOwnCompaction logBytes=544 nextSeq=4, want 0/0 — compactIfDueLocked did not run after CommitGroup TestRecordsArrivingDuringTheEncodeSurvive nextSeq = 29 after the swap, want 24 TestFailedCompactionResyncsLogBytesWithReality logBytes = 88, want 0 TestAFailureAfterTheLogRenamePoisonsTheStore timed out after 30s waiting for the compaction to reach the point after the rename ``` And three are, I think, assumptions in the tests rather than defects in the tree: - `TestAnUnreadableBinaryIsNotSkipped` (`packaging/licenses`) and `TestAnUnreadableSubtreeUnderstatesRatherThanFails` (`wallet/localnode`) make something unreadable with `chmod`, which does not deny reads on Windows. - `TestAMissingNoticeIsReported` (`packaging/licenses`) matches a path inside an error message with a forward slash; Windows prints `licenses\golang.org\x\crypto\LICENSE`. ## What I am asking Mostly whether any of this is already known, and whether `windows/amd64` is meant to pass `make test` at all — `docs/OPERATING.md` lists it among the published targets and `EXPECT_KEYS_RANDOMX` includes `windows-amd64-randomx`, but nothing in the tree says the suite is expected to be green there, and the CI pipeline runs only inside the Linux canonical container. Group 2 I would expect you want regardless of the answer. I am happy to send patches for group 4's three test-only assumptions, which are small and self-contained. Groups 1 and 3 I would rather not touch before you say what the intended behaviour is. This came out of investigating #36; the toolchain half is answered there.