Filename collision
A filename collision occurs when distinct required file names resolve to the same destination entry under a naming or lookup policy.
Identity boundary: stored spelling, canonical Unicode equivalence and case-insensitive lookup are different properties. Linux ext4 documents name-preserving, per-directory case-insensitive lookup; Windows also exposes per-directory case-sensitivity controls. Do not infer destination rules from the operating-system name alone. [1] [2]
Verification consequence: content equality cannot establish that every required directory entry survives. In Hesela's fixed application-transform experiment, two equal-content names collapse to one while both content checks pass. Preserve lossless original names, the intended mapping and a complete output inventory alongside payload checks. This is a scoped acceptance-test lesson, not a filesystem emulator or a backup-product failure rate. [4]
Evidence scope: Basu and colleagues study resource-type collisions and resulting data or metadata changes. Their 2022 preprint motivates destination-specific checks, not a claim that all current copy tools share one behavior. [3]
Relations
Advantages
- Explicit collision handling can prevent accidental merging of distinct required entries.
Limitations
- A generic Unicode transform does not establish a particular filesystem's complete name-resolution behavior.
- Single-component collision checks do not cover links, parent components, pre-existing targets or concurrent changes.
Citations
- Linux kernel documentation: ext4 case-insensitive file name lookups
- Microsoft Learn: per-directory case sensitivity
- Basu, Sampson, Qian and Jaeger (2022): Unsafe at Any Copy, arXiv:2211.16735v1
- Hesela: Restoring file names: when matching hashes hide a lost entry
Sources & caveats
- Primary documentation, historical preprint and controlled synthetic observations; no current product vulnerability claim.