Keeping folder structure and permissions when you zip

You zip a project folder, send it to a colleague, and they report that the scripts will not run, a folder is missing, or there is a strange __MACOSX folder they did not expect.

An archive is supposed to be a faithful copy. How faithful depends on the format, the tool that created it and the tool that opens it.

Folder structure: nearly always fine

ZIP, 7z and tar all store the relative path of each file, so the folder hierarchy is reconstructed on extraction. That part is reliable.

Two things to decide:

Include the top folder or not. Compressing a folder in Finder includes the folder itself, so extracting produces Project/…. Selecting the files inside and compressing them produces a ZIP whose contents land loose in the destination. The first is almost always what the recipient expects.

Empty folders. Most tools include them, but some older extractors skip empty directories. If an empty folder matters — a placeholder for output, say — put a small README in it.

Permissions: preserved, sometimes

Unix-like systems, including macOS, store permissions with each file: who may read, write and execute it. For most documents it does not matter. For scripts and command-line tools, the execute permission is the difference between running and "permission denied".

ZIP can store Unix permissions, and archives created on a Mac — by Finder or the zip command — usually do. Whether they are restored depends on the extractor. macOS's Archive Utility and unzip restore them. Many Windows tools ignore them. A ZIP that has passed through Windows and been re-zipped has usually lost them.

tar was designed for Unix and preserves permissions, ownership and timestamps reliably. For moving code or tools between Macs and Linux machines, .tar.gz is the safer choice.

7z stores Windows-style attributes well; Unix permission support depends on the tool that created it.

If a script arrives without execute permission, the fix is:

chmod +x script.sh

Symbolic links: the tricky part

A symbolic link is a small file that points at another path. Projects, app bundles and developer tools use them heavily.

When archiving, a tool can:

• store the link as a link, which is correct but depends on the extractor recreating it,
• follow the link and store the target's contents, which duplicates data and breaks the structure,
• skip it.

The command-line zip follows links by default; zip -y stores them as links. tar stores them as links.

On extraction, cautious tools treat links with suspicion, because a malicious archive can use a link to write outside the destination folder. That is a sensible security check, and it means a link-heavy archive may be refused or have its links skipped by a safety-focused extractor.

For anything that depends on symbolic links — app bundles, frameworks, some development environments — use tar, or ditto, described below.

Mac metadata and __MACOSX

Mac files can carry extended attributes — Finder tags, download quarantine flags, custom icons — and occasionally older resource forks.

ZIP has no standard place for these. Finder's Compress stores them in a separate hidden folder called __MACOSX inside the archive, using files that start with ._. When extracted on a Mac by Archive Utility, they are recombined invisibly. On Windows or Linux, they appear as clutter.

If the recipient is not on a Mac, you can create a ZIP without them:

ditto -c -k --norsrc --keepParent Project Project.zip

and exclude .DS_Store files — Finder's per-folder view settings — by deleting them first, or with the zip command's -x option.

Apps and code-signed bundles

Code-signed apps and bundles are sensitive to changes in their contents, including symbolic links and extended attributes. Apple's own recommended way to zip a signed app is ditto:

ditto -c -k --keepParent MyApp.app MyApp.zip

This preserves everything the signature depends on. A ZIP made by a tool that follows links or drops attributes can produce an app that macOS reports as damaged.

Which format when

• Documents and media, any recipient: ZIP.
• Scripts, code or tools between Macs and Linux: tar.gz.
• Signed apps or bundles: ditto-created ZIP.
• Large, compressible content where the recipient can open it: 7z.
• Recipient on Windows: ZIP without Mac metadata.

Whatever you choose, test extraction into an empty folder before sending, and if you can, on the kind of machine the recipient uses.

Where Ziploom fits

Ziploom is an archive utility for Apple silicon Macs that creates ZIP and 7Z archives from files and folders, keeping folder structure, and extracts RAR, ZIP and 7Z, with optional password support.

On extraction it applies the caution described above: safety checks cover unsafe paths, symbolic links, suspicious compression ratios, oversized jobs and available disk space before files are installed at the destination. That is the right behaviour for archives from other people. For link-heavy developer material and signed app bundles, tar and ditto remain the better tools, and we would rather say so.

You choose how existing destinations are handled, follow progress, and reveal the output in Finder. All processing stays on your Mac, with no accounts, analytics, advertising, telemetry or network features.