Repair a corrupt (NUL-byte) placeholder SHA at read time

[tyrielv]

Warning

Do NOT publish / mark ready until BOTH: (1) #2074 is completed (approved + finalized), AND (2) #2074 has been merged into vnext. This PR is stacked on #2074 (which is stacked on #2071) and targets vnext. Until #2074 lands in vnext, the diff below includes #2071 + #2074 as well as this repair. Once #2074 is in vnext, rebase this branch so the diff reduces to just the repair. Keep as DRAFT until then.

What this does

Repairs a corrupt (NUL-byte) placeholder content-id at read time instead of only failing cleanly.

When a user process reads a virtualized placeholder whose stored content-id is corrupt — 40 NUL bytes instead of a hex blob SHA — GVFS cannot hydrate it from that content-id. #2074 makes the read fail cleanly (no crash, no retry storm). This PR goes one step further and repairs the underlying data so the file works again.

Root cause (NUL-byte, not AllZeroSha)

A placeholder stores its content-id (the 40-char blob SHA) as UTF‑16 in the ProjFS reparse point. A corrupt placeholder decodes back to a content-id of 40 NUL characters (\u0000 ×40) — literal on-disk corruption. This is not GVFSConstants.AllZeroSha (40 ASCII '0', which is valid hex and yields directory "00").

Telemetry evidence

• Durable, localized corruption: the same 1–4 files per machine fail repeatedly over multiple days until something rewrites the placeholder (~61 machines / ~6.2K events over 30 days; ~643 events / 16 machines over 7 days). This recurring per-file failure is the real user harm — and it is exactly what repair fixes.
• Not a 2.0 regression: spans ≥4 GVFS builds (1.0.25164, 25314, 26014, 26098) — old, version-agnostic, rare.
• Triggering processes are readers (git.exe, copilot.exe, Code.exe) — they don't cause the corruption; the placeholder was already corrupt.
• The authoritative path→SHA still exists: the path is still projected, and GitIndexProjection.GetProjectedFileInfo returns the correct SHA for it, so the corrupt content-id is recoverable from the path.

Design (read-time self-heal)

In WindowsFileSystemVirtualizer.GetFileStreamHandlerAsyncHandler:

1. Plumb virtualPath and the request's BlobSizesConnection into the handler.
2. When the decoded SHA is not a valid hex SHA, recover the authoritative SHA for virtualPath from the git index projection and hydrate from that instead of the corrupt content-id.
3. A successful hydration writes the whole file, which converts the placeholder into a full file on disk — the corrupt content-id is superseded and future reads never call back, so the file is repaired for good.
4. If the path is no longer projected (deleted/renamed), the projected SHA is itself invalid, or the recovered SHA cannot be hydrated → fall back to the same clean, non-crashing FileNotAvailable as Fail blob hydration cleanly on a malformed (NUL-byte) placeholder SHA #2074.

Why not rewrite the content-id in place?

We deliberately do not call UpdateFileIfNeeded to rewrite the content-id. Confirmed empirically against real inbox ProjFS with a throwaway probe:

• Serving the full content converts the placeholder to a full file, so a second read issues no GetFileData callback — hydration alone is the repair.
• UpdateFileIfNeeded on the file mid-read returns 0x80070020 (ERROR_SHARING_VIOLATION) because the reader holds the file open.
• A corrupt placeholder is only injectable from the owning virtualization instance (WritePlaceholderInfo accepts an all-NUL content-id); an external FSCTL_SET_REPARSE_POINT rewrite is blocked (ERROR 1359).

That last point is why this behavior is covered by unit tests rather than a functional test — the corruption cannot be injected into a real mount from outside the provider.

Telemetry funnel

Paired with #2074's *_MalformedBlobSha detection:

• Repaired: GetFileStreamHandlerAsyncHandler_MalformedBlobShaRepaired (Warning) with the recovered SHA — lets us watch the corrupt-placeholder population drain.
• Repair miss: GetFileStreamHandlerAsyncHandler_MalformedBlobShaRepairFailed (Warning) with a reason (ProjectionMiss / InvalidProjectedSha / ProjectionException / HydrateFailed), then a clean fail.

Relationship to the stack

• Stacked on Fail blob hydration cleanly on a malformed (NUL-byte) placeholder SHA #2074 (tyrielv/fix-invalid-sha-hydration), itself stacked on Split blob-hydration and directory-enumeration failure telemetry by cause #2071. Fail blob hydration cleanly on a malformed (NUL-byte) placeholder SHA #2074 is the graceful-fail fallback for every repair-miss branch here.
• Split blob-hydration and directory-enumeration failure telemetry by cause #2071: a repair miss stays telemetry category Unexpected; a successful repair simply succeeds. No new BlobHydrationFailureCategory value.

Why vnext, not master (2.0)

Per the branch model: master is the shippable/stabilization line; vnext is next-train behavioral work. This repair is a new behavioral change on the read path (projection lookup, a possible cache-server download, placeholder repair, edge cases like deleted/renamed paths) for an old, rare, pre-existing corruption. Adding it to the 2.0 stabilization line would spend stabilization risk on a rare problem that is not worse in 2.0. #2074 (the crash / graceful-fail fix) already removes the crash and retry storm and correctly targets master.

Tests

WindowsFileSystemVirtualizerTests (unit):

• Repair success from the projection → emits *_MalformedBlobShaRepaired, completes Ok.
• Non-projected path → emits *_MalformedBlobShaRepairFailed, fails cleanly.
• Recovered SHA cannot hydrate → emits *_MalformedBlobShaRepairFailed, fails cleanly.
• Valid content-id → hydrates normally with no repair telemetry.

Full unit suite: 906 passed, 0 failed (11 pre-existing ignored).