Problem: Zipped directory not processed correctly because of root folder

[cmhosale]

Expected behaviour
Given a standard zipped package with a top level directory and both "objects" and "metadata" subdirectories,
Archivematica ignores the top level directory created when unzipping the zip package and correctly processes the object and metadata subdirectories. (This is what happens with a zipped bag transfer type, and we expected standard transfer "zipped directory" to be the same.)

Current behaviour
When Archivematica unzips a standard transfer (aka "Zipped directory"), it doesn't ignore or eliminate the top level directory, it treats it as the main object package. It does not correctly process the object and metadata subdirectories, instead treating those all as objects. The top level directory, metadata, and objects folder all end up in the AIP's object folder.

Steps to reproduce
Structure a package in a directory named "test_transfer". The directory has two subdirectories - "objects" and "metadata" - with the usual content in both. Zip up the "test_transfer" directory as a ".zip" and submit it as a standard transfer. Archivematica will not process the metadata and objects correctly.

Your environment (version of Archivematica, operating system, other relevant details)
Archivematica 1.18 running on Ubuntu 22.04.5

---

For Artefactual use:

Before you close this issue, you must check off the following:

• All pull requests related to this issue are properly linked
• All pull requests related to this issue have been merged
• A testing plan for this issue has been implemented and passed (testing plan information should be included in the issue body or comments)
• Documentation regarding this issue has been written and merged (if applicable)
• Details about this issue have been added to the release notes (if applicable)

[replaceafill]

Thanks for reporting this, @cmhosale. From a review of the original implementation and the associated documentation and tests from #682, it appears that the current .zip behavior matches the original design, although the documentation could make the expected structure clearer:

Zipped directory: Zipped directory transfers are a variant of the default transfer type in Archivematica. All materials can be transferred using the Zipped directory transfer type; the material just happens to be in a .zip, .tgz, or .tar.gz file at the outset. When a Zipped directory transfer starts, the zip will be decompressed and the material then processed using the Standard transfer workflow documented above. The internal structure of a zipped directory transfer matches that of the standard transfer and so can either be a loose collection of files, or more structured, for example, including an objects and metadata directory including Archivematica's special files such as metadata.csv or identifiers.json.

There is an additional inconsistency that the documentation does not currently capture. Although .zip, .tgz, and .tar.gz are listed together, Archivematica expects different internal structures:

• For .zip, the archive root becomes the transfer's top-level directory. Therefore, objects/ and metadata/ must be directly at the archive root. Unlike the Zipped bag workflow, an additional enclosing directory is not removed.
• For .tgz and .tar.gz, Archivematica extracts into the parent processing directory and expects the archive to provide a containing directory matching the archive's base name. This historical requirement is also reflected in archivematica-sampledata#74.

For example, the expected structures are:

transfer.zip
├── objects/
└── metadata/

and:

transfer.tar.gz
└── transfer/
    ├── objects/
    └── metadata/

We could clarify the documentation with wording such as:

The required internal structure depends on the compression format. For a .zip transfer, the archive root is treated as the transfer's top-level directory, so directories such as objects and metadata must be placed directly at the archive root. For .tgz and .tar.gz transfers, all content must be contained in a top-level directory whose name matches the archive filename without its extension.

Supporting ZIPs with an additional enclosing directory would be a separate behavior change. It would require careful design because that directory may be an intentional part of the transfer hierarchy.

[cmhosale]

Thanks for looking into this. I wouldn't expect tar.gz or .tgz to behave differently than .zip. It would make more sense for all standard transfers to have the same expectations and behaviors regardless of archive file format type. I'd expect Archivematica to have a function where it looks two levels deep and, if there are objects and metadata folders (or other typical signs of an archivematica structured transfer), identifies the transfer as structured and processes the objects and metadata folders.

That being said, updating the documentation would help, so thank you for doing that.