What's wrong
FileScanner.ScanForFiles (FileDeduplicator/FileScanner.cs:52) converts every enumerated path with file.As<AbsoluteFilePath>(). The root path gets the same conversion in Verbs/BaseVerb.cs:20. ktsu.Semantics.Paths 5.8.0 rejects any path that:
- contains
<, >, | or NUL, or
- is longer than 256 characters.
Both are legal on Linux and macOS, and on Windows with long paths enabled. The resulting ArgumentException isn't caught, so one such file anywhere in the tree aborts the entire run before anything is listed or hashed.
Repro
These were run with the real binary built from current main.
Special character in a file name:
mkdir t1 && echo x > t1/a.txt && echo x > t1/b.txt && echo y > "t1/notes <draft>.txt"
FileDeduplicator Scan -p t1
Unhandled exception. System.ArgumentException: Cannot convert ".../t1/notes <draft>.txt" to AbsoluteFilePath
at ... FileScanner.ScanForFiles ... FileScanner.cs:line 52
Long path: a tree containing one file whose full path is about 274 characters. Scan and Deduplicate (with y piped in) both die with the same exception, and the obvious duplicates a.txt and b.txt in that tree are never handled.
Why it matters
Deep trees such as node_modules or nested build output routinely have paths over 256 characters. A single file named like notes <draft>.txt makes Scan, DryRun, Stats and Deduplicate unusable on that whole root, and the user gets a stack trace instead of a result.
Suggested fix / acceptance criteria
- In
ScanForFiles, wrap the conversion in try/catch. Report each path that can't be represented and skip it, the same way the hasher already reports and skips unreadable files.
- Optionally, raise the length and character limits in ktsu.Semantics.Paths so they follow the platform instead of Windows' legacy
MAX_PATH and reserved characters.
- Add a test in which a tree containing a
</| file name and a path over 256 characters still scans and finds the other duplicates.
What's wrong
FileScanner.ScanForFiles(FileDeduplicator/FileScanner.cs:52) converts every enumerated path withfile.As<AbsoluteFilePath>(). The root path gets the same conversion inVerbs/BaseVerb.cs:20. ktsu.Semantics.Paths 5.8.0 rejects any path that:<,>,|or NUL, orBoth are legal on Linux and macOS, and on Windows with long paths enabled. The resulting
ArgumentExceptionisn't caught, so one such file anywhere in the tree aborts the entire run before anything is listed or hashed.Repro
These were run with the real binary built from current
main.Special character in a file name:
Long path: a tree containing one file whose full path is about 274 characters.
ScanandDeduplicate(withypiped in) both die with the same exception, and the obvious duplicatesa.txtandb.txtin that tree are never handled.Why it matters
Deep trees such as
node_modulesor nested build output routinely have paths over 256 characters. A single file named likenotes <draft>.txtmakesScan,DryRun,StatsandDeduplicateunusable on that whole root, and the user gets a stack trace instead of a result.Suggested fix / acceptance criteria
ScanForFiles, wrap the conversion in try/catch. Report each path that can't be represented and skip it, the same way the hasher already reports and skips unreadable files.MAX_PATHand reserved characters.</|file name and a path over 256 characters still scans and finds the other duplicates.