Fix exception check .NET 9

[alinpahontu2912]

Fixes #131053

Customer Impact

Flaky tar tests.

Found internally - Windows symlinks are always created as files, not directories. Depending on the build, it can throw either during creation of a symlink that represents directory structure or when parsing it. This change fixes the flaky test.

Regression

Caused by earlier change in the area.

Testing

Reenabled failing CI tests.

Risk

Low.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates a Windows-specific tar extraction test to tolerate OS/build-dependent exception behavior when extracting nested entries through a type-mismatched symlink (file symlink pointing at a directory), while still validating that directory traversal is rejected and nothing escapes the destination root.

Changes:

• Broaden the Windows assertion to accept either UnauthorizedAccessException or IOException from TarFile.ExtractToDirectory.
• Expand the test comment to document why different Windows builds surface different exception types for the same underlying scenario.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
  "version": 5,
  "last_dispatched_commit": "47cc2b67251cdfdd1a9fb3ae6ef8552ace7bb72f",
  "last_dispatched_base_ref": "release/9.0-staging",
  "last_dispatched_base_sha": "89cb9dc4661289d4c86f514bbe8b9e4d12343b76",
  "last_reviewed_commit": "47cc2b67251cdfdd1a9fb3ae6ef8552ace7bb72f",
  "last_reviewed_base_ref": "release/9.0-staging",
  "last_reviewed_base_sha": "89cb9dc4661289d4c86f514bbe8b9e4d12343b76",
  "last_recorded_worker_run_id": "29747439062",
  "review_attempt_commit": "",
  "review_attempt_base_ref": "",
  "review_attempt_count": 0,
  "max_review_attempts": 5,
  "review_history_format": "holistic-review-disclosure-v1",
  "review_history": [
    {
      "commit": "47cc2b67251cdfdd1a9fb3ae6ef8552ace7bb72f",
      "review_id": 4735591453
    }
  ]
}

[github-actions]

Holistic Review

Motivation: Justified. The security-regression test ExtractToDirectory_RejectsChainedSymlinkDirectoryTraversal_WithNestedFile is flaky on Windows because a directory-targeted symlink is materialized as a file symlink (FileInfo.CreateAsSymbolicLink), so the rejection surfaces as either UnauthorizedAccessException (during ResolveLinkTarget in the traversal-safety walk) or IOException (creating a directory over the existing file symlink), depending on the OS build. Hard-asserting a single type produced spurious failures on the release/9.0-staging branch.

Approach: Sound. The change narrowly relaxes only the Windows branch to accept both exception types via Assert.ThrowsAny<Exception> plus an is IOException or UnauthorizedAccessException assertion, while preserving the strict Assert.Throws<IOException> on non-Windows. Crucially, the security invariant checks (outside/ directory and pwned.txt must not exist) are retained unchanged, so the test still verifies nothing escapes the destination regardless of which exception is thrown. Test-only, no product code touched.

Summary: ✅ LGTM. The relaxation is scoped to the platform-specific non-determinism and keeps the meaningful escape-prevention assertions intact, so it fixes the flakiness without weakening the regression's security guarantee. The failure message includes the unexpected exception ($"Unexpected exception type: {ex}") which aids future diagnosis.

---

Detailed Findings

✅ Test correctness — Escape guarantee preserved

The post-extraction assertions (lines 465–467) that outside/ and outside/pwned.txt are never created run on all platforms and are unchanged. This is the security-relevant part of the test; accepting a broader set of exception types on Windows does not weaken it because a successful traversal escape would still fail those checks.

💡 Optional — Slightly broader catch than necessary

Assert.ThrowsAny<Exception> accepts any exception and then re-validates the type. This is fine and arguably clearer given the explanatory comment, but the two acceptable types could equivalently be asserted directly. Not a blocker.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 55.2 AIC · ⌖ 10.5 AIC · ⊞ 10K

[alinpahontu2912]

/ba-g test failures are unrelated to my change

[karelz]

Test-only change, approved