Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.
Reject ambiguous archive member names before extracting the sprite package. Two stored entries can target the same destination after normalization, even when their strings differ. Decide whether a name is unique within the recipient's path rules, not merely unique in the ZIP listing.
Key Takeaways
- Inspect the complete member set before extraction.
- Detect exact duplicates and destination-equivalent paths.
- Never depend on whichever duplicate an extractor happens to choose.
The container can hide a name collision
The Python ZIP documentation explicitly discusses archives containing duplicate member names. A directory listing or name-based lookup does not make duplicates a reliable delivery convention.
There are also collisions created at the destination. A package might contain a path with a redundant current-directory component and another direct path, or names differing only in a way the target filesystem treats as equivalent. Which file survives can depend on the extraction tool and environment.
Define the destination identity
Use a fixed archive root and a documented output naming policy. List all members before writing them. For each, retain its original name and derive the proposed destination according to the package's rules.
Path normalization and real-path operations have different purposes. Normalizing a string alone does not prove where a filesystem link leads. For this audit, keep the name-collision check separate from containment and link checks.
Compare destination identities as a set. Report both conflicting original members together. Avoid silently keeping the first or last entry, because neither position establishes which art revision was approved.
Example: two copies of the same idle
A packaging script collects hero/idle.png from an approved export folder and a second entry named hero/./idle.png from a temporary folder. The two images show different boot colors. The raw names differ, but normal path interpretation can place them at one destination.
The repair is to identify the intended source revision and remove the unintended member from package assembly. Do not ask the recipient to delete one after extraction, when the overwritten candidate might no longer be visible.
Apply the same review to case-equivalent names on supported targets. Preserve a readable report that maps each rejected source to its conflicting destination.
Rebuild from an unambiguous inventory
A manifest should describe the accepted member set, not just repeat the archive's raw names. If stored as JSON, follow the interoperability considerations in RFC 8259 and avoid using duplicate object names as a substitute for a collision report.
After rebuilding, verify the archive member count, its unique destination count, and references from the sample scene. Inspect a clean extraction and confirm it contains the selected revision of the idle animation.
This is a proposed package audit, not an executed extractor comparison. It does not claim that all programs normalize names identically. If the release supports several environments, test each declared environment and document any restrictions rather than accepting an ambiguous package.
Related workflow
See game asset pack preview zip inventory check for the adjacent failure. Keep the animation handoff checklist with the package and record visual decisions in the art reference board.
Prepared by the FrameSprite Workflow Team. Editorial method · Corrections. Primary documentation checked 2026-10-20.
Top comments (0)