Skip generated icons by file name, not by full path

[matt-edmondson]

Fixes #116

The defect

Directory.GetFiles returns full paths, and IconHelper.cs:119 tested the whole string:

if (file.Contains(".new.png"))

So a directory anywhere above the input could decide that every file below it had already been generated. The contract has never been about paths — README.md:265 and CLAUDE.md:107 both say names: "Files whose names contain .new.png are skipped".

The failure is the worst shape a batch tool can have: total, silent, and reported as success. Nothing is written, nothing is logged per file, and the process exits 0.

The change

if (Path.GetFileName(file).Contains(".new.png", StringComparison.Ordinal))

Ordinal, not the OrdinalIgnoreCase the issue suggests. string.Contains(string) is already ordinal, so Ordinal is what the code does today made explicit, and the fix stays confined to the reported defect. Case-insensitivity would be a second, independent behaviour change: .new.png is not a marker the tool ever writes — nothing in the codebase produces it, it is purely a user-facing convention that README.md documents — so the tool's own output settles nothing about whether Already.New.PNG should be skipped. On Linux those are distinct files. That call is worth its own issue rather than riding along in a path-versus-name fix.

Tests

Two, because the obvious over-correction here is to stop matching on names as well:

test	catches
SkipsOnTheFileNameRatherThanTheContainingPath	the defect — two ordinary files under icons.new.png.dir/in, both expected to be written
SkipsOnTheFileNameEvenBelowAMatchingPath	a fix that drops the check entirely — a marked and an unmarked file in that same directory, one written

The second matters because the first passes if the skip is simply deleted. Together they pin the check to exactly the name.

Proved failing without the fix. Reverting only IconHelper/IconHelper.cs and keeping both tests takes the suite from 8 failures to 10 — the two new ones, and nothing else moves:

failed SkipsOnTheFileNameRatherThanTheContainingPath (81ms)
failed SkipsOnTheFileNameEvenBelowAMatchingPath (2ms)
  total: 75   failed: 10   succeeded: 65

Verification

• dotnet build IconHelper.sln -c Release — succeeded, 0 warnings, 0 errors (this repo runs analyzers as errors)
• dotnet test IconHelper.sln -c Release — 75 total, 67 passed, 8 failed

About those 8 failures

They are all GoldMasterTests.OutputMatchesTheGoldMaster, and they are not caused by this change — unmodified main gives 73 total, 65 passed, the same 8 failed.

The cause is this container, not the repository: the gold master fixtures under IconHelper.Test/GoldMaster/Input/ are Git LFS objects, git-lfs is not installed here, and a shallow clone therefore leaves them as pointer files. file reports them as ASCII text beginning version https://git-lfs.github.com/spec/v1. ImageSharp cannot decode a pointer file, ProcessDirectory counts it as a failure, and every case trips its Assert.AreEqual(1, result.Written) guard.

Nothing in this change touches decoding or the gold master path, and CI, which materializes LFS content, should see all 75 green. Flagging it rather than leaving it to be rediscovered: any agent working this repository in a container without git-lfs will see these 8 failures and should not read them as a regression.

🤖 Generated with Claude Code

https://claude.ai/code/session_012betVHk3gFcj5RYkEe4vrm

---

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