Clarify MatchCasing does not affect directory path resolution

[rtmongold]

Closes #115356

Summary

This PR clarifies that EnumerationOptions.MatchCasing applies only to file name pattern matching and does not affect directory path resolution.

On case-sensitive file systems (e.g., Linux and macOS), directory paths must match the exact casing even if MatchCasing = CaseInsensitive.

Motivation

Users may assume that MatchCasing affects the full path when performing searches. In reality, it only applies to file name pattern matching, which can be misleading on case-sensitive systems. This update improves documentation to reduce confusion.

Changes

• Updated XML doc comment in EnumerationOptions.cs (runtime repo)
• Updated API XML (EnumerationOptions.xml) with <remarks> clarifying:
  • Scope is limited to file name matching
  • Directory paths are unaffected
  • Default behavior is platform-dependent
• Optional example included in API XML to illustrate Linux behavior

Example (API docs)

Directory.GetFiles("/tmp/data", "*.TXT",
    new EnumerationOptions { MatchCasing = MatchCasing.CaseInsensitive });

[rtmongold]

Changed the tab to spaces.

[rtmongold]

This is a docs-only PR. The branch appears to go out of date frequently due to ongoing commits in main.

I’ve rebased to the latest main—happy to rebase again if needed, but it may require a maintainer rebase at merge time.

[Copilot]

Pull request overview

This PR updates the EnumerationOptions.MatchCasing API documentation to clarify that it affects only name matching against the search pattern and does not change how directory paths are resolved on case-sensitive file systems.

Changes:

• Updated the XML doc comment for EnumerationOptions.MatchCasing to scope it to pattern matching.
• Added remarks stating directory path resolution is unaffected, and casing must still match on case-sensitive file systems.

[rtmongold]

/ba-g networking failure in Helix (devicectl NSPOSIXErrorDomain 49)

[rtmongold]

The WASM Helix job failed due to image pull (Exit Code -4).
This is a known flaky infra issue. Could someone rerun the job? /azp run

[jozkee]

Suggested change

	/// This property affects only how entry names (file and directory names) are matched against the search pattern during enumeration.
	/// It does not affect directory path resolution or traversal. On case-sensitive file systems
	/// (common on Linux or when using a case-sensitive volume), directory paths must match the exact casing
	/// regardless of this setting; on case-insensitive file systems, path resolution follows the behavior
	/// of the underlying file system. The default is to match the platform defaults.
	/// Directory path resolution or traversal is always performed by the operating system's file system layer, independent of this property.
	/// The default value is <see cref="MatchCasing.PlatformDefault"/>.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
  "version": 5,
  "last_dispatched_commit": "c12ba5d84576edf80489904712a16bdc60e34e9d",
  "last_dispatched_base_ref": "main",
  "last_dispatched_base_sha": "9a4041e6e93abe56b6d4786bc73509fb60ef13ab",
  "last_reviewed_commit": "c12ba5d84576edf80489904712a16bdc60e34e9d",
  "last_reviewed_base_ref": "main",
  "last_reviewed_base_sha": "9a4041e6e93abe56b6d4786bc73509fb60ef13ab",
  "last_recorded_worker_run_id": "29676146448",
  "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": "c12ba5d84576edf80489904712a16bdc60e34e9d",
      "review_id": 4730520991
    }
  ]
}

[github-actions]

Holistic Review

Motivation: Closes #115356. On case-sensitive file systems, Directory.GetFiles(path, pattern, EnumerationOptions) with MatchCasing.CaseInsensitive does not make directory path components case-insensitive — only file/entry name matching against the search pattern is affected. Users reasonably assumed MatchCasing applied to the full path, leading to Could not find part of the path surprises. This PR clarifies the documented semantics.

Approach: Documentation-only change to the XML doc comment on EnumerationOptions.MatchCasing. The <summary> is expanded to state the property governs entry-name matching against the search pattern, and the <remarks> explicitly notes that directory path resolution/traversal is unaffected and that case-sensitive file systems require exact directory-path casing regardless of this setting. No behavioral code changes, so no build/test impact.

Summary: The clarification is accurate and directly addresses the confusion reported in the issue. The wording is clear and correct: MatchCasing indeed only influences name matching, and directory traversal uses the OS file system semantics. This is a safe, low-risk documentation improvement. One minor nit (inline): the change removes the <value> element that previously described the property value; the repo's docs guidance recommends retaining <value> on properties. That is optional and non-blocking. Overall this LGTM.

Note

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

Generated by Holistic Review · 48.3 AIC · ⌖ 10.3 AIC · ⊞ 10K

[github-actions]

The revised doc drops the <value> element that previously described the property value ("One of the enumeration values that indicates the case matching behavior."). The repo docs guidance (.github/prompts/docs.prompt.md) recommends using <value> on properties. Consider retaining a <value> element alongside the expanded <remarks> so the generated API reference still renders a value description.