core: the collision guard compares planned names byte for byte, and Windows filesystems are case-insensitive

[otsobide]

What happens

plan_names refuses two entries that would be written under one name, which is the guarantee that stops a rename from quietly destroying a file. The comparison is byte for byte.

Windows and macOS default filesystems are case-insensitive. Two entries whose planned names differ only in case are one file there, and the guard does not see it.

Reproduction

rewrite_entry("Report.txt") = "Report.txt"
rewrite_entry("report.txt") = "report.txt"
byte-equal? false            -> no collision reported

Both are then written, the second over the first, and the returned listing names two files where the disk holds one. The user is told both were extracted.

Where it bites hardest

A rename can create the collision, which is the case the guard exists for. WHAT?.txt answered with _ and what_.txt already in the archive collide on Windows and not in the comparison, so the very substitution the user was asked to supply is what loses their data.

Note on scope

Case folding is not a one-liner and should not pretend to be. Simple ASCII lowercasing covers the realistic archive and is honest about its limits; full Unicode case folding is a different conversation, and the Turkish dotless i is the usual reason. Worth deciding which one this guard promises, and saying so in the doc comment either way.

The rules are already data (NameRules::windows() versus ::unix()), so case-insensitivity belongs there as another field rather than as a #[cfg], which is what keeps it testable from a Mac.

Found while auditing the Windows CI failure that led to #88.

[otsobide]

Resolved in v0.10.0, though not the way this issue proposed.

The guard this is about no longer exists. Extraction stopped renaming entries
altogether — a name the host cannot write exactly as the archive spells it now
fails the whole extraction (NameError::Unwritable) instead of being adjusted —
so NameError::Collision is constructed nowhere, and the case this issue calls
worst is unreachable: WHAT?.txt can no longer be answered with _, so it can
no longer land on an existing what_.txt.

Verified against main: no construction of NameError::Collision remains in
apps/core/src.

One half of what this documented is NOT fixed, and deserves a successor
rather than being lost here. Two entries of the archive's own that differ only
in case are still both written, the second over the first on Windows and on a
default macOS volume, and the returned listing still names two files where the
disk holds one. NameRules has no case-folding field — verified, there is no
case_insensitive or to_ascii_lowercase in names.rs.

That half predates this issue and was explicitly permitted before it too
("extraction has always let the second win"), so it is a separate, narrower
problem: not about a guard that mis-compares, but about extraction reporting
files it did not leave behind.