fix: skip a file the hashing pass cannot read instead of aborting [patch]

[matt-edmondson]

Fixes #126

The problem

FileHasher.HashFiles caught only IOException, and UnauthorizedAccessException does not derive from it. Because hashing runs under Parallel.ForEach, a single permission-denied file escaped the delegate and surfaced as an AggregateException out of HashFiles — uncaught by the calling verb or Program.Main — killing the entire hashing phase and discarding the hashes every other thread had already produced.

Deduplicator.StillMatchesGroup already catches both types for the equivalent re-hash before deletion, so the two read paths disagreed about the same failure.

The fix

A catch (UnauthorizedAccessException ex) branch alongside the IOException one. The shared reporting body moved into a small ReportSkipped helper so the two branches cannot drift apart later.

Testing

HashingSkipsAnUnreadableFileAndStillHashesTheRest hashes three paths, one of them unreadable, and asserts the other two are still hashed and the unreadable one is simply absent.

The denial is arranged with a directory standing in for a file, which File.OpenRead rejects with UnauthorizedAccessException on every platform for every user. This is deliberate: chmod 000 on a real file proves nothing under a privileged process, and the test would pass whether or not the exception were handled — a false green on CI runners and in root containers.

Verified the test catches the bug by running it against the unfixed code first:

System.AggregateException: One or more errors occurred. (Access to the path '.../denied' is denied.)
 ---> System.UnauthorizedAccessException: Access to the path '.../denied' is denied.
 ---> System.IO.IOException: Permission denied
failed HashingSkipsAnUnreadableFileAndStillHashesTheRest

That trace is also direct confirmation of the root cause: the inner exception is an IOException, but the one thrown is the UnauthorizedAccessException wrapping it, which the old catch could never match.

With the fix applied the test passes, and the full suite is green — 45 passed, 1 skipped, 0 failed (45 passing, up from 44).

🤖 Generated with Claude Code

https://claude.ai/code/session_01NPXBwr1rm8hybVmmWhx7wd

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[matt-edmondson]

CI: the one red check is not this PR's

github-advanced-security is failing, and it is not caused by this change. The job log shows the Copilot autofind agent aborting on an account quota, not on anything in the diff:

errorType: 'quota',
statusCode: 402,
[cause]: [Error: You have exceeded your monthly quota (Request ID: 5803:3E7D11:582714:69A947:6AB1947B)]

Everything that actually exercises the code is green: Test on ubuntu-latest, windows-latest and macos-latest, plus SonarCloud, CodeQL, Analyze (csharp) and Analyze & Release.

Two further points confirming it is environmental:

• The same check passed on fix: insert the test project into a solution exactly once [patch] OAICLI#47 eleven minutes later (20:43 vs 20:32), so the quota is fluctuating rather than the diff being at fault.
• It failed identically on fix: survive an unreadable directory and a symlink cycle while scanning [patch] #130, an independent branch off main touching a different file.

I have not re-run it: rerun-failed-jobs returns 403 This workflow run cannot be retried for this workflow, and a re-run would not clear a quota error anyway. There is no fix to port into this PR — the remedy is on the account's Copilot quota, outside this repository. Flagging rather than working around it, since suppressing a security check is not something this PR should do.

---

Generated by Claude Code