What's wrong
IconHelper.ProcessDirectory (IconHelper/IconHelper.cs ~L138–141) always writes <name-without-extension>.png into the output directory. Nothing checks whether an earlier input in the same run already produced that name, or whether the output directory is the input directory.
Repro
- Input directory with
save.png (40×40) and save.bmp (20×20), output directory out, then run ProcessDirectory.
- Observed: "2 file(s) written",
failed = 0, but out/ contains only save.png at 20×20. The 40×40 result was overwritten, and which one survives depends on Directory.GetFiles order.
--input X --output X with a 200×100 red icon.png.
- Observed: the source is replaced in place by the 64×64 recoloured mask, with no warning and exit code 0.
Expected: every input's result is kept, or the collision is reported as a failure, so the written count matches the files on disk. Source images are never silently destroyed.
Why it matters
The summary line says more files were written than exist. In the second case, the original artwork is lost with a success exit code, which is easy to hit by pointing both options at the same icon folder. The .new.png skip logic that remains in the code suggests outputs were once meant to stay separate from inputs.
Suggested fix
- Track the output file names written in a run. When a second input maps to the same name, count it as failed (or skip it with a message).
- Reject an output directory that resolves to the input directory in
Arguments validation, or at least require an explicit overwrite flag for it.
Acceptance: tests covering both cases.
What's wrong
IconHelper.ProcessDirectory(IconHelper/IconHelper.cs~L138–141) always writes<name-without-extension>.pnginto the output directory. Nothing checks whether an earlier input in the same run already produced that name, or whether the output directory is the input directory.Repro
save.png(40×40) andsave.bmp(20×20), output directoryout, then runProcessDirectory.failed = 0, butout/contains onlysave.pngat 20×20. The 40×40 result was overwritten, and which one survives depends onDirectory.GetFilesorder.--input X --output Xwith a 200×100 redicon.png.Expected: every input's result is kept, or the collision is reported as a failure, so the written count matches the files on disk. Source images are never silently destroyed.
Why it matters
The summary line says more files were written than exist. In the second case, the original artwork is lost with a success exit code, which is easy to hit by pointing both options at the same icon folder. The
.new.pngskip logic that remains in the code suggests outputs were once meant to stay separate from inputs.Suggested fix
Argumentsvalidation, or at least require an explicit overwrite flag for it.Acceptance: tests covering both cases.