fix: normalize the paths callers supply to validate

[perryqh]

Summary

validate <paths> compared caller-supplied paths against project-relative ones without reducing them to the same form first. What that costs depends on the shape of owned_globs, and both outcomes are wrong:

owned_globs shape	what happens to a mishandled path	symptom
directory-anchored ({gems,ruby,…}/**/*.rb)	matches nothing, dropped before any ownership query	exit 0, having checked nothing
**-leading (**/*.rb)	survives the filter, queried in the caller's spelling	well-owned file reported unowned

The first is the dangerous one: silent, and in the unsafe direction. A pre-commit hook or CI job reports success on a file it never looked at.

Split out of #125 so it can be reviewed on its own — it fixes bugs that exist on main today, independent of that PR's premise.

The path forms that hit this

./ruby/app/x.rb and ruby/a/../x.rb were never reduced at all.

Absolute paths were reduced with strip_prefix against a root that need not agree with them about symlinks. cli.rs canonicalizes --project-root, so on macOS — where TMPDIR lives under /var, a symlink to /private/var — a caller passing the TMPDIR spelling fails to strip. And a library caller building its own RunConfig, which is how the code_ownership gem calls in, can pass an unresolved root against a resolved path — the mirror image. Fixing only one side leaves the other failing exactly as silently, so the retry resolves both.

Absolute paths were also echoed back in the caller's spelling rather than project-relative, since the raw string was what got reported.

Examples 1–4 below are the four resulting shapes; 5–8 are the rest of what this branch fixes.

Examples

Every transcript below is real output from main vs. this branch, same fixture, same command. ruby/app/unowned.rb is a file with no owner; ruby/app/models/payroll.rb is owned by @PayrollTeam.

1. ./-prefixed path, directory-anchored owned_globs → silent pass

The dangerous shape. valid_project's globs are {gems,config,javascript,ruby,components}/**/*.{rb,tsx,erb}, so an unreduced ./ruby/... matches nothing and is dropped before any ownership query.

$ codeowners --project-root . validate ./ruby/app/unowned.rb    # BEFORE
exit=0                                                          # ← never checked

$ codeowners --project-root . validate ./ruby/app/unowned.rb    # AFTER
Unowned files detected:
  ruby/app/unowned.rb
exit=1

A pre-commit hook or CI job invoked this way reports success on a file it never looked at.

2. Absolute path, root resolved but path not → silent pass

cli.rs canonicalizes --project-root, so on macOS it becomes /private/var/... while a caller passing the TMPDIR spelling supplies /var/.... strip_prefix fails, the path stays absolute, and the glob filter drops it.

$ codeowners --project-root /tmp/proj validate /tmp/proj/ruby/app/unowned.rb   # BEFORE
exit=0                                                                        # ← never checked

$ codeowners --project-root /tmp/proj validate /tmp/proj/ruby/app/unowned.rb   # AFTER
Unowned files detected:
  ruby/app/unowned.rb
exit=1

3. Absolute path, path resolved but root not → silent pass

The mirror image, reachable only through the library API, since the CLI always canonicalizes the root. This is how the code_ownership gem calls in — it builds its own RunConfig. From the probe that found it:

root      = /var/folders/.../.tmpXld81u
file      = /private/var/folders/.../.tmpXld81u/ruby/app/unowned.rb
errors    = []                                        ← unowned file, no error reported

Resolving only the supplied path fixes example 2 and leaves this one failing identically, which is why the retry resolves both sides.

4. **-leading owned_globs → the opposite symptom

Same cause, and here the unreduced path survives the filter and gets queried in the caller's spelling. It matches no CODEOWNERS entry, so a perfectly well-owned file is reported unowned — note the report echoing ./ back:

$ codeowners --project-root . gv ./ruby/app/models/payroll.rb   # BEFORE
Unowned files detected:
  ./ruby/app/models/payroll.rb                                  # ← it IS owned
exit=1

$ codeowners --project-root . gv ./ruby/app/models/payroll.rb   # AFTER
exit=0

This is why the fix cannot be evaluated against one fixture alone, and why the tests cover both glob shapes.

5. A deleted file in the changeset → failed the commit

git diff --name-only lists deletions, so a deleted path reaches validate in normal use. A deleted file cannot have an owner.

$ rm ruby/app/models/payroll.rb
$ codeowners --project-root . gv ruby/app/models/payroll.rb     # BEFORE
Unowned files detected:
  ruby/app/models/payroll.rb
exit=1                                                          # ← blocked, for deleting a file

$ codeowners --project-root . gv ruby/app/models/payroll.rb     # AFTER
exit=0

6. Absolute path naming a symlink → checked the wrong file

Fixed by the second commit, and a bug the first commit introduced: it canonicalized the whole path, which follows a symlinked file. Here ruby/app/link_to_unowned.rb → unowned.rb:

$ codeowners --project-root . validate /tmp/proj/ruby/app/link_to_unowned.rb
Unowned files detected:
  ruby/app/unowned.rb            # ← BEFORE: names the target, not the file asked about

  ruby/app/link_to_unowned.rb    # ← AFTER: names the symlink

Both exit 1 here because both paths are unowned, which is exactly why the regression test asserts on which path is named rather than on pass/fail. Point the symlink at an owned file instead and the before-case exits 0 — a false pass on a file the caller never mentioned.

The retry now resolves only the parent and re-attaches the file name, so example 2 stays fixed without following the leaf.

7. Same defect in a neighbouring public API

codeowners_query::teams_for_files_from_codeowners, reached from the public runner::teams_for_files_from_codeowners, relativized with the same relative_to_buf that passes unstrippable paths through. A /var/... path against a /private/var/... root was looked up in the CODEOWNERS file as an absolute path, matched no entry, and came back None — reported as unowned.

Fixing validate while leaving the bulk-lookup entry point beside it would have made this branch's claim narrower than it reads. Its keys were already the relativized form rather than the caller's spelling, so they were inconsistent depending on whether strip_prefix happened to succeed; they are now consistently relative.

8. Repeated .. cancelling its own escape → wrong file reported

Found while acting on review feedback, and introduced by this branch's first commit. A leading .. is retained so the caller can detect an escape, but pop() cannot tell it apart from a real component, so a later .. popped it — and ../../a came out as a.

$ codeowners --project-root . validate ../ruby/app/unowned.rb      # single ..
exit=0                                                             # correctly out of scope

$ codeowners --project-root . validate ../../ruby/app/unowned.rb   # double ..
Unowned files detected:
  ruby/app/unowned.rb                          # ← out-of-project path, reported as in-project
exit=1

Same class as example 6 — answering about a different file than the caller named — and the single-.. case behaving correctly is exactly what made it look handled.

Relatedly, the filesystem retry is now gated to absolute paths. A relative path is interpreted against the project root by contract, so the lexical pass is the whole interpretation; retrying resolved it against the process CWD instead, which meant identical arguments could mean different files depending on where the command ran from.

The fix

path_utils::project_relative resolves . and .. lexically and reports failure rather than passing an unstrippable path through — which is how a /var/... path came to be compared against project-relative ones in the first place.

Lexically, not by canonicalizing: the project walk records symlink paths rather than their targets, so resolving symlinks here would produce paths that match no walked file.

Deleted paths are now skipped

Example 5 above. The gem already filters its list by File.exist? before calling in, so this matches what its callers see today and extends it to direct library callers. Only a definite "not there" skips: try_exists().unwrap_or(true) keeps a path whose status is unknown, because a visible error is investigable and a silent pass is not.

A fixture that did not contain what three tests claimed

Three tests asserted on valid_project/ruby/app/unowned.rb, which does not exist — valid_project has to validate cleanly, so it ships no unowned file. They passed only because a nonexistent path was reported as unowned, which means they were covering typo handling while claiming to cover unowned files. Skipping nonexistent paths removes that accident.

Repointed at invalid_project, which has a real one, and narrowed to assert the path and exit status rather than the category wording, so they don't depend on how the report is phrased.

The tests assert the mechanism, not the outcome

Worth calling out, because the first draft of tests/supplied_path_normalization_test.rs was nearly worthless and passed against unfixed code.

It pointed at invalid_project, whose **-leading globs mean a mishandled path is spuriously reported rather than dropped — and the assertion only checked that "unowned.rb" appeared somewhere in the output. So it passed for entirely the wrong reason: only 2 of 9 tests failed against unmodified main.

Rewritten against valid_project (anchored globs, where mishandling drops the path) with an injected unowned file, and now asserting that the report names the normalized path and does not echo the caller's spelling. Without that, a test cannot distinguish "checked correctly" from "mishandled and spuriously reported."

7 of the 9 fail without this change. The 2 that pass are the plain-relative control and the outside-the-project skip, both of which already worked. One test covers the **-glob direction, since the symptom there is the opposite.

Note for reviewers

Runner::validate_files here is the existing read-CODEOWNERS-back implementation. #125 replaces that method wholesale, so the ~30 lines of normalization wiring inside it are transitional — but path_utils::project_relative, project_relative_path, the fixture correction and the whole test file survive that change unaltered. #125 will be rebased onto this branch.

The third commit addresses review feedback on the second, and fixes a ..-handling bug (example 8) found while doing so.

Unrelated, found while doing this: the pre-commit hook fails in any git worktree. Git exports GIT_DIR to hooks, the tests spawn git subprocesses that inherit it and read the wrong repository, and 11 git-dependent unit tests fail. Reproducible against unmodified main with GIT_DIR=<path> cargo test --lib. Worth a separate fix in .rusty-hook.toml.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes path-handling bugs when callers supply explicit file paths to validate / generate-and-validate, by normalizing those inputs into the same project-relative form used elsewhere in the pipeline (including a symlink-aware retry that avoids following symlinked files). It also skips deleted paths (common in diffs) and adds targeted tests to prevent silent false-passes and misreported “unowned” results caused by mismatched path spellings.

Changes:

• Normalize caller-supplied paths in Runner::validate_files and in the public CODEOWNERS bulk-lookup API before filtering/querying.
• Skip definitely-nonexistent paths during validate runs to avoid failing commits that delete files.
• Update and add tests to cover normalization edge cases (dot paths, .., absolute paths with root/path symlink disagreements, deleted paths, and symlink leaf behavior).

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/runner.rs	Normalize supplied paths up-front, skip deleted files, and query CODEOWNERS using normalized project-relative paths.
src/path_utils.rs	Add lexical project-relative normalization plus a filesystem-assisted retry that avoids canonicalizing symlinked file leaves.
src/ownership/codeowners_query.rs	Apply the same normalization to the bulk CODEOWNERS lookup used by a public API.
src/cli.rs	Update CLI help text to document path resolution and skipping deleted paths.
tests/validate_files_test.rs	Fix fixtures/assertions to validate genuinely unowned files and avoid relying on phrasing.
tests/supplied_path_normalization_test.rs	Add comprehensive regression coverage for supplied-path normalization and deletion behavior.

Suppressed comments (1)

src/cli.rs:54

• Same as above: the \ continuation keeps the indentation as literal spaces, so the generated help text will contain a large gap before “resolved relative…”.

        #[arg(help = "Optional list of files to validate ownership for (fast mode for git hooks). Paths are \
                   resolved relative to the project root; ones that no longer exist are skipped, so a \
                   changeset that deletes files is not reported as unowned.")]

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[perryqh]

Not a defect — Rust's string continuation escape strips the newline and the leading whitespace on the next line, so the indentation never reaches the string.

Verified against the rendered output on this branch:

$ codeowners validate --help
  [FILES]...  Optional list of files to validate ownership for (fast mode for git hooks). Paths are resolved relative to the project root; ones that no longer exist are skipped, so a changeset that deletes files is not reported as unowned.

Counting interior multi-space runs in that description gives 0. The only gap is clap's own column alignment between [FILES]... and the description text, which is unrelated to the continuation.

(This would be a real problem with concat! or adjacent string literals, which don't strip anything — just not with \.) Leaving the help text as-is, and likewise for the suppressed duplicate on line 52.

[perryqh]

Good catch — fixed in 9e204f1 by gating the test behind #[cfg(unix)] rather than making it portable.

Windows isn't a supported target (CI is ubuntu-latest + macos-latest, and the release artifacts are macOS x86_64/aarch64 and Linux x86_64/aarch64 only — see .github/workflows/ci.yml and dotslash-config.json), so there's nothing to port it to. But your point that cargo test should compile on all targets stands regardless, and the gate costs nothing.

[perryqh]

Correct, and it was worse than surprising — fixed in 9e204f1, which now returns early unless path.is_absolute().

The framing that convinced me: a relative path is interpreted against the project root by contract (that's what --help promises), and the lexical pass is the whole of that interpretation. So a lexical failure means the path escapes the root, and retrying resolved it against the process CWD instead — quietly switching interpretation frames, so identical arguments would mean different files depending on where the command ran from. Plus the wasted syscall you noted.

Chasing this also surfaced a real bug in lexically_normalize that the retry was masking. A retained .. was indistinguishable from a real component to pop(), so a later .. popped it and ../../a cancelled its own escape:

$ codeowners validate ../ruby/app/unowned.rb      # single `..`
exit=0                                           # correctly out of scope

$ codeowners validate ../../ruby/app/unowned.rb   # double `..`
Unowned files detected:
  ruby/app/unowned.rb                            # ← out-of-project path, reported as in-project
exit=1

Same class as the symlink bug the previous commit fixed — answering about a different file than the caller named — and the single-.. case behaving correctly is exactly what made it look handled. Both are now covered by unit tests.