Fail blob hydration cleanly on a malformed (NUL-byte) placeholder SHA

[tyrielv]

Problem

When a user process reads a virtualized placeholder file whose stored content-id (SHA) is corrupt — specifically 40 NUL bytes (\u0000 × 40) — GVFS builds a loose-object path from it and Path.Combine throws System.ArgumentException: Illegal characters in path:

System.ArgumentException: Illegal characters in path.
   at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
   at System.IO.Path.Combine(String path1, String path2, String path3)
   at GVFS.Common.Git.GitRepo.GetLooseBlobState(String blobSha, Action`2 writeAction, Int64& size)
   at GVFS.Common.Git.GitRepo.TryCopyBlobContentStream(String blobSha, Action`2 writeAction)
   at GVFS.Common.Git.GVFSGitObjects...TryCopyBlobContentStream...
   at GVFS.Platform.Windows.WindowsFileSystemVirtualizer.GetFileStreamHandlerAsyncHandler(...)

ArgumentException is not in RetryWrapper.IsHandlableException (only HttpRequestException, IOException, RetryableException), so it bypasses both the retry logic and the download fallback in GVFSGitObjects.TryCopyBlobContentStream and propagates to the virtualizer's outer catch (Exception), which returns FileNotAvailable to ProjFS. The placeholder can never hydrate, so the failing read repeats indefinitely — a retry storm.

Not AllZeroSha

This is not GVFSConstants.AllZeroSha. AllZeroSha is 40 ASCII '0' characters, which yields directory "00" and does not throw. The failing SHA is literally 40 NUL bytes — a corrupt placeholder content-id.

Where the malformed SHA comes from

A placeholder's content-id is the 40-char SHA encoded as UTF-16 (80 bytes) and stored in the ProjFS placeholder reparse point (FileSystemVirtualizer.ConvertShaToContentId = Encoding.Unicode.GetBytes(sha)). On read, GetShaFromContentId decodes those 80 bytes with Encoding.Unicode.GetString. If that on-disk content-id region is zeroed — a corrupt placeholder from an interrupted/partial placeholder write, a crash/power-loss during placeholder creation, or disk corruption — the decode yields 40 \u0000 characters.

Telemetry impact

Signature: VFS.Error, ErrorMessage contains TryCopyBlobContentStream, Exception contains Illegal characters in path and GetLooseBlobState.

• Top blob-hydration failure cause on the LKG field build 1.0.26014.1 (38 machines).
• ~61 machines / ~6.2K events across 30 days; the corruption is old and version-agnostic (observed across ≥4 GVFS builds: 1.0.25164, 25314, 26014, 26098), and the same 1–4 files per machine fail repeatedly for days — the placeholder never self-heals.
• Produces permanent failures and retry storms — the worst single machine emitted ~2.49M error events in 30 days.

Fix

A minimal, surgical behavior fix (graceful-fail, defense-in-depth). Reject a malformed SHA before it is turned into a filesystem path:

• GitRepo.GetLooseBlobState returns LooseBlobState.Invalid (a clean, non-retryable miss) when the SHA is not 40 hex characters, so Path.Combine can never throw here again.
• GitRepo.LooseObjectExists guards the same Path.Combine.
• GVFSGitObjects.TryCopyBlobContentStream short-circuits a malformed SHA before the retry loop, so a bogus SHA never triggers a doomed 404 download or a retry storm.
• SHA1Util.IsValidShaFormat is now null-safe; SHA1Util.ToLoggableShaString renders the bad value with non-hex characters escaped (\uXXXX) so telemetry stays greppable and free of control characters.
• WindowsFileSystemVirtualizer.GetFileDataCallback routes the request's logged sha through ToLoggableShaString, so the terminal hydration-failure RelatedError (and every sink using that request metadata) can no longer record raw NUL/control bytes. No-op for a valid hex SHA.

All three guard sites emit the same greppable Warning event (*_MalformedBlobSha, with the offending value under the sha metadata key) at Warning level, with no unhandled exception (an expected, handled corrupt-placeholder read is a Warning, not an Error).

Telemetry category stays "Unexpected"

Per an existing decision, a malformed SHA gets no dedicated telemetry category. This branch was developed on top of the (now-merged) blob-hydration telemetry work (#2071), which added out BlobHydrationFailureCategory to TryCopyBlobContentStream; the malformed-SHA short-circuit sets failureCategory = Unexpected. The case previously reached the virtualizer's outer catch and was tagged Unexpected there; now that it no longer throws, it returns cleanly and the virtualizer tags its terminal telemetry Unexpected via the out-param — same bucket, no double-logging, no new category. The paired *_MalformedBlobSha warning lets an analyst separate this deterministic case from genuinely-unexpected exceptions.

Relationship to #2071 (merged)

Developed stacked on #2071 ("Split blob-hydration and directory-enumeration failure telemetry by cause"), which has since merged to master. This branch has been rebased onto master, so the diff below is now just this fix (the #2071 changes are in the base). No further coordination needed.

Not in scope (follow-up)

• No placeholder repair. This PR fails gracefully. A read-time self-heal that re-derives the authoritative SHA from the git-index projection and rewrites the corrupt placeholder — with a detected → repaired / repair-failed telemetry funnel — is a separate follow-up PR targeting vnext (2.1): it is new, destabilizing behavior for an old, non-2.0-regressing problem, so it does not belong in the 2.0 stabilization line. This PR's graceful-fail guards remain the fallback for the repair-miss case.

Tests

• GVFSGitObjectsTests.TryCopyBlobContentStreamFailsCleanlyForCorruptAllNullByteSha / ...ForOtherMalformedShas: a 40-NUL-byte SHA, a 40-char SHA with an embedded path-illegal character, and other malformed SHAs return false from both GitRepo.TryCopyBlobContentStream and GVFSGitObjects.TryCopyBlobContentStream with no ArgumentException (Assert.DoesNotThrow), no download/retry is attempted, the out category is Unexpected, and the *_MalformedBlobSha diagnostic events are actually emitted (verified via a small MockTracer enhancement that records RelatedEvent names).
• SHA1UtilTests: null-safety and ToLoggableShaString escaping (mixed valid/NUL, control chars, high code points).
• Full unit suite: 897 passed, 0 failed (11 pre-existing ignores).

Review

Reviewed with a multi-lens self-review (correctness / security / design / tests / async / risk-rollout) over two iterations; feedback applied (consistent *_MalformedBlobSha event names and sha metadata key across all guards; escaped telemetry at the single virtualizer chokepoint; explicit no-throw / no-download / emission assertions). No outstanding code findings; the only rollout note is to re-point any dashboard/alert keyed on the old Illegal characters in path exception signature at the new *_MalformedBlobSha events / the Unexpected category tag (the top-level hydration-failure RelatedError still fires, so affected machines remain visible).