Decide relative path validity from the string, not the working directory

[matt-edmondson]

Fixes #196

The bug

IsDirectoryPathAttribute called File.Exists(value) on every value, and IsFilePathAttribute called Directory.Exists(value). For a path that is not fully qualified, those resolve against the process's current working directory — so whether a path was valid depended on what files happened to sit beside whatever was running.

That reached consumers rather than staying in tests. On Linux .NET publishes an extensionless apphost named exactly after the project, so a test project called ktsu.BlastMerge.Test leaves a file called ktsu.BlastMerge.Test next to the test assembly. AppData.AppDomain converts the app domain name to a RelativeDirectoryPath, File.Exists found the apphost, and the conversion threw:

System.FormatException: Cannot convert "ktsu.BlastMerge.Test" to RelativeDirectoryPath

On Windows the apphost carries a .exe suffix, so nothing was found and the same string validated. Nothing about the name differed between the two platforms — only what was on disk beside the process.

The fix

Both attributes now run the existence check only when the path is fully qualified, which is the one case where it names a single location and the question is answerable. Anything else is validated by shape alone.

This is the first of the three options the issue weighed ("restrict the existence check to absolute paths and validate relative ones by shape alone"). It needs no API change and no base directory threaded through validation, so it fixes the live breakage without committing the library to a larger design.

Path.IsPathFullyQualified is used rather than IsPathRooted, which also excludes Windows drive-relative paths like C:foo — those resolve against a per-drive working directory and are ambient in exactly the same way.

IsFilePathAttribute carried the mirrored defect in the same code shape. Fixing only the reported half would have left RelativeFilePath broken by the identical mechanism, so both are changed together; the diff is the same four lines twice.

Tests

Four tests in PathValidationAttributeTests, all reproducing or pinning real behaviour:

Test	Asserts
IsDirectoryPathAttribute_RelativeNameCollidingWithFileInWorkingDirectory_ShouldPass	The reported failure mode: a relative name stays valid with a same-named file in the cwd
IsFilePathAttribute_RelativeNameCollidingWithDirectoryInWorkingDirectory_ShouldPass	Its mirror, with a same-named directory
IsDirectoryPathAttribute_AbsolutePathOfExistingFile_ShouldFail	The existence check is kept where it is answerable
IsFilePathAttribute_AbsolutePathOfExistingDirectory_ShouldFail	Its mirror

The two collision tests were verified to fail against the unmodified attributes and pass with the fix — reverting only the two source files and re-running gives exactly the reported Cannot convert ... exception on both. The two absolute-path tests pass either way by design: they pin behaviour the fix must preserve.

Each creates its fixture under a GUID-suffixed name and cleans up in a finally, so they are safe under the assembly's method-level parallelization and mutate no process-global state (notably, they do not change the working directory).

Verification

• dotnet build — clean, 0 warnings (ktsu.Sdk builds warnings as errors)
• dotnet test Semantics.Test — 1202 tests, 0 failed (1194 passed, 8 skipped as Windows-only)
• SonarCloud analyzers via .sonarlint/sonar-local.props — the 5 findings reported are all pre-existing, in TextValidationAttributesTests.cs and Paths/DirectoryNameTests.cs, neither of which this PR touches. No new findings.

Not run: dotnet format --verify-no-changes, which fails on this repo independently of this change — it does not run the source generator, so the generated quantity types are undefined during its compile.

Docs

docs/validation-reference.md described both attributes in terms that no longer match. Updated with the qualification and a note on how to ask the existence question about a relative path (AsAbsolute(baseDirectory) first, then validate).

Follow-up, out of scope here

The issue reports the failure via ktsu.AppDataStorage → ktsu.BlastMerge. Those live in other repos and are not verified by this PR; confirming them green on Linux is the remaining acceptance item on #196 once this ships.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01UArBGBWxw5dSrddFUcYccd

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud