"Error hashing" messages show only the file name, so the failing file can't be found in a tree with repeated names

[matt-edmondson]

What's wrong

FileDeduplicator/FileHasher.cs:54 (ReportSkipped) prints:

Console.WriteLine($"  Error hashing {filePath.FileName}: {ex.Message}");

It prints only the file name, not the path.

Failure scenario

In a real tree, the same file names repeat many times: index.js, README.md, IMG_0001.jpg. When one of them can't be read (locked, permission denied, or removed mid-scan), the user sees Error hashing IMG_0001.jpg: Access denied and has no way to tell which of the dozens of copies failed.

Stats makes this worse:

• It only reports a count, "Unreadable files: N" (Verbs/Stats.cs:69-72).
• The hashing line is the only place the failing file is ever named.

Every other diagnostic in the tool prints the full path (Deduplicator.cs:77, :81, :154).

Suggested fix

• Print {filePath} (the absolute path) in ReportSkipped.
• Optionally, have HashFiles return the failed paths so the verbs can list them again in their summary.

Acceptance criteria

• The error line contains the file's absolute path.
• The existing hashing-error test in FileDeduplicator.Test/FileScannerAndHasherTests.cs (around line 282) asserts the full path.

[matt-edmondson]

Triage

• Category: Improvement
• Priority: Low. This is a diagnostics quality issue: the message shows the file name without its path, so the failing copy can't be located. There is no data impact.
• Area / suggested assignee: FileHasher.ReportSkipped (FileHasher.cs:54). Owner: @matt-edmondson
• Duplicates / in progress: none found. No open PR covers it.
• Next step: print the absolute path, and update the hashing-error test in FileScannerAndHasherTests.cs to assert it. Returning the failed paths so the verbs can list them in their summary is optional.

---

Generated by Claude Code