An update archive must stay inside its own staging area

A ZIP can contain the expected product documents and still be unsuitable for import. The member names inside it determine where an application intends to put those files. Accepting the outer filename does not establish that every destination belongs to the update.

This fictional investigation follows a catalogue team's asset package. It concerns the receiving boundary before publication, rather than the accuracy of the documents themselves. The platform and path rules below are assumed inspected facts for this example; another importer needs its own supported contract and security review.

Establish the intended destination before opening the package

The owner supplies package A-61 for a draft catalogue update. The agreed receiver runs on Linux and uses a fresh, private staging directory for each batch. It accepts ordinary files under relative paths within two approved folders: documents/ and images/. Approved nested folders are allowed. Publication is a later, separate action.

A-61 contains these three entries:

The third name asks to move out of the batch directory before entering shared/. The receiving process must not decide that it is harmless because the other entries look right, or silently rename it and continue.

The original A-61 file is retained in quarantine with its recorded checksum. Staff can refer to that exact evidence when asking the supplier to correct the package. Nothing from it is published.

Locate the failure before it becomes a write

The inspected draft importer joins each member name to the staging root and writes entries as it encounters them. It has no whole-package destination check. That would make the outcome depend on entry order: acceptable files could already have been written when the application reaches the invalid member.

In the isolated investigation, the team inspects the proposed destinations without performing those writes. Resolving the third member puts it outside A-61's assigned staging root. The defect is therefore present even though no PDF is missing and all three members can be listed successfully.

The Python ZIP documentation illustrates why the actual API matters: zipfile.Path leaves validation of member names to its caller. Other extraction methods have their own documented handling. A receiving application should establish what its chosen method does rather than assume that every ZIP interface supplies the same boundary.

Define a narrow supported package

For this importer, the owner and developer agree to reject the whole batch before extraction if any member violates the contract. The preflight examines every member, including entries that appear after valid ones.

The accepted names use forward-slash relative paths under the two approved top-level folders. Absolute paths, drive-style paths, backslashes, . or .. components, duplicate destinations and file/directory conflicts are rejected. The receiver also rejects symbolic links and other unsupported member types; an ordinary path-containment check does not establish that a link is safe.

The staging area is newly created, owned by the receiving process and not shared with another writer. Accepted files are written only after the full preflight passes, under the same destination rules. The application does not follow pre-existing links or reuse an arbitrary user-supplied directory. A platform change would require these assumptions to be reviewed.

These checks address the demonstrated destination failure. File content validation, permitted types, decompression limits, malware handling and release permission remain separate parts of the import design. A successful path check is not a complete security assessment.

Ask the owner for a corrected package

The receiving team reports the exact rejected member and the agreed package structure. It does not remove the entry behind the owner's back and describe the remainder as the original delivery.

The owner determines that settings.json came from an unrelated working folder and supplies A-62 containing only the two intended catalogue assets. A-62 has its own recorded checksum. Its relationship to rejected A-61 is documented, while the original evidence stays unchanged.

The complete preflight now passes. In the isolated trial, the two files are staged at their intended relative locations, and their contents match the two approved source assets. The catalogue owner can review the draft sheet and photograph. Passing the import has not published them or approved their commercial content.

Check the rule, including the cases that should fail

The acceptance record covers more than the corrected package:

The published catalogue is also unchanged throughout the trial. Its files are outside this receiving operation, and publication still requires its own authorised review.

The final decision is to retain the importer with a defined preflight and staging boundary, not replace the catalogue system. The owner accepts A-62 for draft review, retains A-61 as rejected evidence and adds the package rules to the supplier handover. That leaves the next operator with a specific response to an invalid update rather than a choice between ignoring an error and trying the same archive again.

Discuss the receiving workflow with a harmless sample package and its intended destinations. The system-connection service can help define what an incoming exchange is allowed to change.