92 Semantics.Paths tests fail on Linux, and main has been red since the matrix added it

[matt-edmondson]

Summary

Test on ubuntu-latest fails on main with 92 failures, all in Semantics.Paths tests. Test on windows-latest passes. Every PR inherits the red job, which is how it was noticed.

	ubuntu-latest	windows-latest
main @ 3b40272 (run)	❌ 92 failed, 1006 passed	✅

Why it started

8b9df02 ("ci: adopt the unified dotnet workflow") added Linux to the test matrix two days ago. Its own commit message says exactly what it was for:

Tests now run on Linux as well as Windows, which is new coverage for libraries that ship netstandard and claim to run anywhere but were only ever tested on one operating system.

The coverage found what it was looking for on the first run. Nothing regressed — this is pre-existing behaviour that had never been exercised.

What is failing

All 92 are path tests that assume Windows semantics: drive letters, \ separators, and the 259-character limit. A sample:

• SemanticPath_RootPath
• SemanticPath_PathLength_Long
• PathOperators_CrossPlatformSeparators_HandleCorrectly
• PathOperators_WithDotPaths_HandleCorrectly
• RelativeFilePath_AsAbsoluteWithBase_ResolvesCorrectly
• RelativeDirectoryPath_Parent_ReturnsCorrectParent
• IsChildOf_WithMixedSeparators_WorksCorrectly
• SemanticFilePath_FileName_WithPathSeparators_ShouldReturnOnlyFileName
• AbsoluteToRelative_RoundTrip_WorksCorrectly

Suggested shape of the fix

Most of these look like test assumptions rather than defects in Semantics.Paths, so the work is mostly to express each expectation in terms of the running platform:

• Build fixtures with Path.Combine and Path.DirectorySeparatorChar instead of literal C:\... strings.
• Take the root from Path.GetPathRoot(Environment.CurrentDirectory) rather than hard-coding C:\.
• Gate the 259-character limit behind [TestCategory("OS-Specific")], which CLAUDE.md already prescribes for exactly this.

Check each one as you go, though — the point of a Linux matrix is to find real bugs, and some of these may be genuine Semantics.Paths defects on a platform where \ is a legal filename character and there is no drive letter. IsChildOf_WithMixedSeparators_WorksCorrectly in particular is worth reading carefully before assuming the test is at fault: treating \ as a separator on Linux would be a library bug, not a test bug.

Acceptance criteria

• Test on ubuntu-latest passes on main.
• Any failure that turned out to be a library defect rather than a test assumption is called out in the PR, with the fix in Semantics.Paths rather than in the test.
• Tests that are genuinely Windows-only carry [TestCategory("OS-Specific")].

Context

Found while working #181. Analysis was posted on #188 and #190 to explain why those PRs left the job red — neither introduced a failure, and both matched main's count exactly.

[matt-edmondson]

Worked this today. Progress, and a change of direction from the fix this issue originally proposed.

Where it stands

	Linux	Windows
before	92 failed	1112 passed
now	32 failed	1112 passed

The 60 fixed so far were incidental: tests that only needed an absolute path in order to exercise something else (an interface cast, a conversion, a type check) and spelled it as a drive-letter literal, which is not absolute on Linux, so construction threw before the test's real assertion was reached. Those now go through a TestPaths.Absolute helper that maps a Windows-style path onto the host. Windows is unaffected: the helper is the identity there, and the suite still passes 1112 of 1112.

The remaining 32 are a design question, not a test problem

They divide cleanly, and every one of them is asking the same thing:

category	count	example
separator and depth semantics	~20	PathDepth_WithMixedSeparators, Normalize_WithDotPaths, IsChildOf_WithMixedSeparators
character validation	7	IsValidDirectoryNameAttribute_DirectoryNameWithColon_ShouldFail
UNC and Windows root	3	IsAbsolutePathAttribute_WithUNCPath_ShouldPass, WindowsRoot_IsInterned
length limits	2	IsPathAttribute_PathOverLimit_ShouldFail

The cause in each case is that the library delegates to host APIs. Path.AltDirectorySeparatorChar is / on Linux, not backslash, so a backslash is not a separator there at all: a\b\c is three segments on Windows and one filename on Linux. Path.GetInvalidFileNameChars() returns a much smaller set on Linux, where : and | are legal in a filename. The length limit is a Windows concept.

Direction

The decision is to make path semantics platform-invariant rather than to make the tests platform-aware as suggested above. A path string should mean the same thing wherever it is evaluated:

• treat both / and backslash as separators everywhere
• apply one invalid-character set everywhere, the stricter Windows one
• apply one length limit everywhere
• recognise UNC form everywhere

The reasoning is that these are semantic path types. A type whose guarantees change depending on the machine evaluating it is the thing this library exists to avoid, and a consumer serialising a path on one host and validating it on another currently gets different answers. Making the tests platform-aware would encode that difference as intended behaviour.

This is a behaviour change for Linux consumers and wants its own release note.

Scope is roughly 15 files in Semantics.Paths: the separator handling in SemanticPath, SpanPathUtilities, Polyfills, InternedPathStrings, the Absolute*/Relative* implementations, and the validation attributes under Validation/Attributes/Path.

Separately

While tracing this I found a distinct defect in the same area that is not about separators or character sets, and it has a wider blast radius because it reaches consumers rather than tests. Filed separately.