The trust report calls it a failure while printing the volume saying otherwise

[ALERTua]

Reported on #72 by the reporter of #3, whose machine answers in German and has FDVDenyWriteAccess set. Their run printed this:

Marking Dev Drive E: as trusted for Defender performance
Could not mark E: as trusted (fsutil exited with code 1).
fsutil devdrv query E: said:
  This is a trusted Dev Drive.
  Dev Drives are protected by anti-virus filters.
  Currently attached dev drive filters:
  WdFilter
The Dev Drive will still work, but without the Defender performance mode trust enables.
Retry by hand with: fsutil devdrv trust /f E:

The first line says the volume is not trusted. The next four are the volume saying it is. A reader has to decide which half of our own message to believe.

Where it comes from

Resolve-DevDriveTrustReport has three branches. Two of them are careful:

• exit 0 and the English phrase matched — report it trusted
• exit 0 and anything else — say so plainly, print what the volume said, and let the reader judge, because the phrase is localized and nothing else on the machine carries the designation

The third is not. On a non-zero exit it returns Outcome = 'Failed' and asserts three things it has not established: that the volume was not marked, that Defender will not run in performance mode, and that a retry is what to do about it. The query output is printed underneath, unread.

This is the repository's own rule turned around. AGENTS.md says never to report success from an exit code alone — but reporting failure from one, while holding a read-back that disagrees, is the same mistake pointing the other way.

What to do

Treat a non-zero exit like the localized case: report what happened without concluding what it means.

• Say that fsutil returned an error code, and give the code.
• Print what the volume answered, as the other branch already does.
• Do not claim the volume is untrusted, and do not claim Defender will run without performance mode. Neither is known.
• The retry line can stay: it is advice, not a verdict, and it costs nothing if the volume is already trusted.

Both careful branches already exist as worked examples in the same function, so this is aligning the third with them rather than inventing anything.

Not established, and worth a line in the answer rather than a guess

Why fsutil devdrv trust /f returns 1 on a volume that is trusted. It could be "already trusted" — a volume formatted with Format-Volume -DevDrive may carry the designation before the call is made — or something about the forced dismount on a virtual disk. It has been seen exactly once, on that machine, and no reasoning here should pretend otherwise.

Scope

dev_drive.ps1: the third branch of Resolve-DevDriveTrustReport. dev_drive.Tests.ps1: the branch already has tests; they pin the wording that is wrong.

[ALERTua]

Updated 2026-08-27 — the guess below is refuted, and the fix is now a different one

"Not established" section, refuted. It said the likeliest reason fsutil devdrv trust returns 1 on an already-trusted volume is that Format-Volume -DevDrive had already marked it, leaving the call nothing to do. Measured on two scratch .vhdx Dev Drives: formatting does leave the volume already trusted — and the forced trust call on it still returns 0, twice in a row. So that is not the explanation. Why that machine returned 1 remains unknown, and there is now one fewer candidate.

The fix changes shape. #111 reads the designation as two volume flags rather than as fsutil's text, and the flags follow trust and untrust exactly. Once the report decides from the bits, the branch this issue is about — "non-zero exit code means the volume was not marked" — has nothing left to decide and goes away entirely, along with the localized-answer branch beside it.

What survives from this issue, and what #111 must still carry: on the path where the bits cannot be read, the report falls back to the exit code and the text, and there it must still not assert a failure it has not established. Say the code, show the answer, stop.

Both are being done on the same branch, so this closes with #111.