How to Create a Zip File

Beginner40-60 minutesWindowsFile Explorer

A zip file is a compressed archive: a single container that holds one or more files and folders in a format that is both smaller than the originals and efficiently transferable as a single unit. For the 57 Studios™ development cohort, the zip archive is the canonical delivery mechanism for Unturned™ mod-source packages, Workshop upload staging bundles, asset review payloads, and milestone snapshot distributions. The ability to create, inspect, and verify archives is therefore not a convenience—it is a core production skill of comparable importance to folder scaffolding or file renaming.

This article presents all five methods by which a Windows user may create a zip archive, beginning with the built-in right-click interface and concluding with PowerShell's scriptable Compress-Archive cmdlet. Beyond mechanical creation, this article addresses compression algorithm selection, archive naming conventions, multi-volume archive production, password protection, archive integrity verification, and the cohort-recommended practices for mod-source distribution. By the conclusion of this article, you will be equipped to select the correct archiving method for any scenario encountered in professional mod development.

Prerequisites

You should have File Explorer open with extensions visible and be comfortable with folder navigation. If you have not yet read How to Create a New Folder, complete that article before proceeding. For methods that require third-party tools, you must have 7-Zip or WinRAR installed; installation procedures for those tools are outside the scope of this article but are covered in the cohort onboarding documentation.

What you will learn

The five methods for creating zip archives in Windows
The functional differences between compression algorithms Deflate, LZMA, and Zstd
How to select the appropriate format and compression level for each use case
Archive naming conventions that communicate version, date, and content at a glance
How to produce multi-volume archives for large distributions
How to apply password protection to sensitive archives
How to verify archive integrity before distribution
Cohort-recommended practices for mod-source and Workshop distribution archives
How to automate archive creation with PowerShell
Archive format comparison for interoperability across platforms

What archive creation actually does

When you instruct any archiving tool to create a zip file, the tool performs a sequence of discrete operations: it reads each source file, applies a compression algorithm to the file's byte stream, encodes the compressed bytes into the archive format's container structure, writes a central directory entry, and closes the archive. The result is a single .zip file whose internal structure is a directory listing followed by the compressed data blocks for each entry.

The central directory is the archive's table of contents. It lists every entry by name, stores each entry's compressed and uncompressed size, and records the byte offset at which the compressed block begins. This structure allows any archive tool to list the archive's contents without decompressing any data—an important property for verification workflows.

Did you know?

The ZIP format specification was published by Phil Katz in 1989 and has since become the most widely supported archive format across all major operating systems. Windows, macOS, and Linux can all open ZIP files natively. This cross-platform compatibility is a primary reason the ZIP format remains the preferred distribution format for mod packages, even when more efficient formats like 7z or zst are available for internal workflows.

Did you know?

A zip file containing a single uncompressed text file is larger than the original file. The archive overhead—the central directory, local file headers, and format metadata—adds a small fixed cost to every archive. For very small files, this overhead exceeds the compression savings. The breakeven point varies by file type, but for most text-based files the overhead is recouped at around 1 KB of content.

Method 1: Right-click → Send to → Compressed (zipped) folder

The built-in Windows right-click method is available on any Windows installation without additional software. It produces a standard ZIP archive using the Deflate algorithm at a moderate compression level.

Navigate to the file or folder you wish to archive in File Explorer.
Select one or more files or folders. To select multiple items, hold Ctrl while clicking each item.
Right-click the selection.
In the context menu, hover over Send to.
Click Compressed (zipped) folder in the submenu.
A new .zip file appears in the same location as the selected items, with the same name as the first selected item and a .zip extension.
The file name is selected for editing. Type the desired archive name and press Enter, or press Escape to accept the default name.

The archive is created in the same parent folder as the source files. If you wish to place the archive in a different location, move it after creation using Ctrl + X and Ctrl + V.

Pro tip

When archiving a project folder for distribution, create the archive from the folder's parent rather than from within the folder itself. Right-click the project folder as a single item and choose Send to → Compressed (zipped) folder. The archive contains the project folder as its root entry, so recipients extract the folder intact rather than receiving a flat collection of files at the archive root.

Common mistake

Selecting files from within a folder and zipping them produces an archive whose root contains individual files, not the folder. Recipients who extract this archive find all files deposited directly into their destination folder, with no intermediate project folder. For mod-source distributions this is typically undesirable. Always zip the folder itself, not its contents, unless the recipient has specifically requested a flat archive.

Method 2: Windows 11 native compress (command bar)

Windows 11 exposes archive creation through the command bar at the top of File Explorer, providing a slightly more discoverable interface than the right-click submenu.

Select one or more files or folders in File Explorer.
Click the ... (More options) button at the right end of the command bar, or right-click for the modern context menu.
On Windows 11 22H2 and later, click Compress to ZIP file directly in the context menu.
Alternatively, with items selected, click the Share group in the command bar and look for the Zip option.
Name the resulting archive and press Enter.

The Windows 11 native compress option is functionally identical to the Send to method—both use the built-in Windows Shell compression, which applies Deflate compression. The method is offered here as a distinct entry because the Windows 11 interface surfaces it differently, and new users encountering the modernised right-click menu may not find the Send to submenu at all.

Best practice

On Windows 11, the modern right-click context menu shows a condensed set of actions. If you do not see a compression option, click Show more options at the bottom of the context menu to access the full legacy context menu, which includes the Send to → Compressed (zipped) folder path.

Method 3: 7-Zip

7-Zip is a free, open-source archiving application that supports a wider range of formats and compression algorithms than Windows' built-in tool. It is the preferred tool for cohort workflows that require the 7z format, LZMA compression, or higher compression ratios than Deflate provides.

Creating an archive with 7-Zip via right-click

Right-click the file or folder you wish to archive.
In the context menu, hover over 7-Zip.
Click Add to archive... to open the full 7-Zip dialog, or click Add to "filename.7z" or Add to "filename.zip" for quick archive creation with default settings.
In the Add to Archive dialog:
- Set Archive format to zip or 7z as required.
- Set Compression level as appropriate for the use case (see the compression level comparison below).
- Set Compression method if you need to override the default for the chosen format.
- Set Split to volumes if creating a multi-volume archive.
- Enter a Password if the archive requires password protection.
Click OK.

7-Zip compression levels

Level name	Level value	Use case
Store	0	No compression; maximum speed; archiving already-compressed files
Fastest	1	Quick packaging where speed matters more than size
Fast	3	Reasonable speed-size balance for large binary assets
Normal	5	Default; appropriate for most mod-distribution archives
Maximum	7	Best compression for text-heavy source distributions
Ultra	9	Highest compression; slowest; for archival-quality storage

For Workshop upload staging packages and mod-source distributions, Normal (5) is the standard level. Ultra compression offers marginal size reduction for binary assets (textures, models, bundles) that are already compressed internally, at the cost of substantially longer archive creation time.

Pro tip

Unity3d bundle files are already compressed internally. Applying Ultra compression to archives that consist primarily of bundle files wastes time while producing archives only marginally smaller than those produced by Normal compression. Apply Ultra only to archives containing primarily uncompressed text, configuration, or source data.

Method 4: WinRAR

WinRAR is a commercial archiving application that supports RAR, ZIP, and several other formats. Its distinguishing features relevant to mod development are recovery records (error-correction data embedded in the archive) and solid archives (a compression mode that compresses multiple similar files together for improved ratio).

Creating an archive with WinRAR via right-click

Right-click the file or folder you wish to archive.
Click Add to archive... in the context menu.
In the Archive name and parameters dialog:
- Set Archive format to ZIP or RAR as required.
- Set Compression method to the desired level.
- Enable Create solid archive for maximum compression on multi-file archives with similar content.
- Enable Add recovery record for archives that will be distributed where transmission errors are possible.
- Enable Set password for protected archives.
- Set Split to volumes if producing a multi-volume archive.
Click OK.

Common mistake

The RAR format offers better compression ratios and built-in recovery records compared to ZIP, but RAR files require WinRAR or a compatible tool to open. Recipients who do not have WinRAR installed cannot open RAR archives without additional software. For mod-source distributions where recipients may have varying software configurations, ZIP remains the safest choice unless you have confirmed all recipients can open RAR files.

Best practice

If you use WinRAR for internal archival workflows (such as long-term project snapshots), consider enabling recovery records for all archives. The recovery record adds approximately 5% to archive size but allows partial recovery of a damaged archive. For archives stored on hardware that may fail, this overhead is a worthwhile investment.

Method 5: PowerShell Compress-Archive

PowerShell's built-in Compress-Archive cmdlet creates ZIP archives without any third-party software. It is the correct choice for automated workflows, batch archive creation, and scripted mod-source packaging pipelines.

Standard usage

powershell

# Archive a single folder
Compress-Archive -Path 'C:\ModProjects\CratesMod' -DestinationPath 'C:\Releases\CratesMod_v1.2.0.zip'

# Archive multiple items
Compress-Archive -Path 'C:\ModProjects\CratesMod\Bundles', 'C:\ModProjects\CratesMod\Workshop' -DestinationPath 'C:\Releases\CratesMod_v1.2.0_dist.zip'

# Archive with date-stamped filename
$date = Get-Date -Format 'yyyy-MM-dd'
Compress-Archive -Path 'C:\ModProjects\CratesMod' -DestinationPath "C:\Snapshots\CratesMod_$date.zip"

Overwriting an existing archive

By default, Compress-Archive fails if the destination file already exists. To overwrite an existing archive, use the -Force flag:

powershell

Compress-Archive -Path 'C:\ModProjects\CratesMod' -DestinationPath 'C:\Releases\CratesMod_v1.2.0.zip' -Force

Updating an existing archive

To add files to an existing archive without replacing the entire archive, use the -Update flag:

powershell

Compress-Archive -Path 'C:\ModProjects\CratesMod\ChangeLog.txt' -DestinationPath 'C:\Releases\CratesMod_v1.2.0.zip' -Update

Common mistake

Compress-Archive -Update adds or replaces individual entries in the archive but does not remove entries that no longer exist in the source. If you have removed files from the source and need the archive to reflect those removals, recreate the archive from scratch with -Force rather than updating the existing one.

Verifying an archive after creation

PowerShell does not include a native archive verification cmdlet, but you can verify integrity using the .NET ZipFile class:

powershell

Add-Type -AssemblyName System.IO.Compression.FileSystem

function Test-ZipIntegrity {
    param([string]$ArchivePath)
    try {
        $zip = [System.IO.Compression.ZipFile]::OpenRead($ArchivePath)
        $entryCount = $zip.Entries.Count
        $zip.Dispose()
        Write-Host "Archive OK: $entryCount entries verified in $(Split-Path $ArchivePath -Leaf)" -ForegroundColor Green
        return $true
    } catch {
        Write-Host "Archive FAILED integrity check: $ArchivePath" -ForegroundColor Red
        Write-Host $_.Exception.Message -ForegroundColor Red
        return $false
    }
}

Test-ZipIntegrity -ArchivePath 'C:\Releases\CratesMod_v1.2.0.zip'

The function opens the archive and reads its central directory. A corrupted archive typically fails at the OpenRead step. Successful completion confirms the central directory is intact; individual entry data can be verified further by enumerating and reading each entry.

Best practice

Run Test-ZipIntegrity as the final step in any automated packaging pipeline. A packaging script that produces a corrupt archive without detecting the corruption is more harmful than a script that fails loudly at the verification step. The verification adds negligible time compared to the archive creation itself.

Compression algorithm comparison

The three algorithms most relevant to mod development are Deflate, LZMA, and Zstd. Each represents a different trade-off between compression ratio, speed, and compatibility.

Algorithm	Typical ratio on mod assets	Speed	Compatibility	Best use
Store (no compression)	1:1	Instantaneous	Universal	Already-compressed binaries, rapid staging
Deflate	1.5:1 – 2:1 on text; near 1:1 on binaries	Fast	Universal	All distribution ZIPs; default for Windows built-in
LZMA	2:1 – 4:1 on text; 1.1:1 on binaries	Slow	7z format; partial ZIP support	7z source archives; archival snapshots
Zstd	1.8:1 – 3.5:1 on text; 1.05:1 on binaries	Very fast	Limited; not native ZIP	Internal pipelines with compatible tooling

Deflate

Deflate is the algorithm defined in the ZIP specification and supported natively by every operating system. For distribution archives, Deflate is the only algorithm guaranteed to open without third-party software on the recipient's machine. Deflate offers good compression for text, configuration files, and source data; its ratio on already-compressed binary files (PNG textures, compiled bundles) is negligible.

LZMA

LZMA (Lempel-Ziv-Markov chain Algorithm) achieves substantially higher compression ratios than Deflate on compressible data at the cost of significantly longer compression and decompression times. It is the native algorithm of the 7z format. Some ZIP tools support LZMA-compressed entries within a ZIP container, but this is not universal—a LZMA-in-ZIP archive may open correctly in 7-Zip while failing in Windows' built-in ZIP handler. Use LZMA exclusively in 7z archives when maximum compression ratio is required.

Zstd

Zstd (Zstandard) is a modern algorithm developed by Facebook's engineering team. It achieves compression ratios comparable to LZMA at speeds substantially closer to Deflate. Native Zstd support is not present in the standard ZIP specification, and Windows does not support Zstd-compressed ZIPs natively as of 2026. Zstd is most useful in internal pipelines where all tools are known to support it. For any distribution where the recipient's tooling is uncertain, Deflate remains the correct choice.

Best practice

Select the compression algorithm based on the archive's intended recipient and use case: Deflate for all external distributions, LZMA (in 7z) for maximum-ratio archival storage, Zstd only in fully controlled internal pipelines. Never use LZMA or Zstd in ZIP-format distribution archives.

Archive format comparison

Beyond the compression algorithm, the choice of archive format affects interoperability, feature availability, and the recipient's ability to open the file.

Format	Extension	Native Windows support	Password protection	Multi-volume	Recovery records	Recommended use
ZIP	`.zip`	Yes (open and create)	Yes (AES-256 in 7-Zip)	No (ZIP split via 7-Zip)	No	All external distributions
7z	`.7z`	No (requires 7-Zip)	Yes (AES-256)	Yes	No	High-compression internal archives
RAR	`.rar`	No (requires WinRAR)	Yes	Yes	Yes	Internal archives where recovery is needed
TAR.GZ	`.tar.gz`	No (Windows)	No	No	No	Cross-platform; Linux-adjacent workflows

For 57 Studios™ mod distributions, the authoritative format is ZIP. All external distributions must be ZIP archives regardless of the compression algorithm used for internal workflows.

Archive naming conventions

A consistent archive naming convention communicates the archive's content, version, and purpose at a glance. The following conventions have been adopted across 57 Studios™ projects.

Convention components

Component	Format	Examples	Required for
Project name	PascalCase, no spaces	`CratesMod`, `HorizonBundle`	All archives
Version	`_vMAJOR.MINOR.PATCH`	`_v1.2.0`, `_v0.9.1-beta`	Distribution archives
Qualifier	`_source`, `_dist`, `_workshop`, `_snapshot`	`_source`	Archives with multiple parallel types
Date	`_YYYY-MM-DD`	`_2026-05-18`	Snapshot archives

Example names

Archive purpose	Example name
Distribution package for Workshop upload	`CratesMod_v1.2.0_workshop.zip`
Mod source package for review	`CratesMod_v1.2.0_source.zip`
Snapshot before a risky refactor	`CratesMod_2026-05-18_snapshot.zip`
Multi-reviewer distribution (all reviewers get the same archive)	`CratesMod_v1.2.0_review.zip`
Internal archival bundle with maximum compression	`CratesMod_v1.2.0_archive.7z`

Common mistake

Naming a distribution archive mod.zip or final.zip is the most common naming failure observed in cohort code review. An archive named mod.zip provides no information about which mod, which version, or which build it contains. A recipient who downloads it cannot determine its contents without opening it. Always include the project name and version in the archive filename.

Best practice

When distributing multiple archive types for the same version (for example, a _source archive and a _dist archive), verify that both archives carry the same version number. A mismatch between source and distribution archive versions has caused multiple review-cycle delays in cohort history.

Multi-volume archives

A multi-volume archive splits a large archive across multiple files of a fixed maximum size. Multi-volume archives are useful when:

Distributing across file-hosting platforms with per-file size limits (most platforms cap single uploads at 2 GB or less).
Copying large archives to storage media with per-file size constraints (some file systems cap files at 4 GB).
Distributing over connections where partial downloads are difficult to resume.

Creating multi-volume archives with 7-Zip

Right-click the source folder and choose 7-Zip → Add to archive....
Set Archive format to zip or 7z.
In the Split to volumes, bytes field, enter the maximum size per volume.
- Common values: 700m (700 MB, fitting a CD-ROM), 4096m (4 GB, fitting a FAT32 drive), 2048m (2 GB, for platforms with 2 GB limits).
Click OK.

7-Zip produces files named ArchiveName.zip.001, ArchiveName.zip.002, and so on. All volumes must be present and in the same folder to extract the archive. Include a README.txt with any multi-volume distribution explaining the extraction procedure.

Best practice

For Workshop-upload multi-volume archives, prefer a single-volume upload whenever the platform permits. Multi-volume distributions add extraction complexity for recipients. Use multi-volume archives only when a single-file distribution is technically impossible due to size constraints.

Password protection

Password-protected archives encrypt their contents so that extraction requires the correct password. Use password protection for:

Source-code packages distributed to restricted reviewers
Archives containing pre-release content not yet cleared for general distribution
Archives sent over unsecured channels where interception is a concern

Password-protecting an archive with 7-Zip

Right-click the source and choose 7-Zip → Add to archive....
In the Encryption section at the bottom of the dialog, enter the password in the Enter password and Re-enter password fields.
Set Encryption method to AES-256. This is the strongest option available and is the required standard for all cohort distributions.
Optionally enable Encrypt file names to prevent recipients from viewing the archive's file listing without the password.
Click OK.

Critical warning

Do not distribute the password for a protected archive through the same channel as the archive itself. If an interceptor captures the archive transmission, they will also capture the password. Distribute the archive through one channel (email attachment, file host) and the password through a separate channel (direct message, Bitwarden send, or voice). Combining both in a single email defeats the purpose of encryption.

Common mistake

Setting a short or obvious password (such as the mod name or the creator's username) provides no meaningful protection. A password-protected archive with a weak password is not a security measure—it is a procedural formality. For any archive with genuine sensitivity, use a randomly generated password of at least sixteen characters from a password manager.

Archive integrity verification

Distributing an archive without verifying its integrity is a process failure. A corrupt archive that reaches a recipient wastes their time and damages the project's distribution reliability record.

Verification with 7-Zip

Right-click the archive file.
Choose 7-Zip → Test archive.
7-Zip reads and decompresses every entry, verifying checksums against the values stored in the archive. A successful test reports Everything is OK. A failed test identifies the corrupt entry.

Verification with PowerShell

The Test-ZipIntegrity function defined in the Method 5 section performs a structural verification of ZIP archives. For a deeper verification that decompresses each entry's data, extend the function:

powershell

Add-Type -AssemblyName System.IO.Compression.FileSystem

function Test-ZipContents {
    param([string]$ArchivePath)
    $errors = 0
    try {
        $zip = [System.IO.Compression.ZipFile]::OpenRead($ArchivePath)
        foreach ($entry in $zip.Entries) {
            try {
                $stream = $entry.Open()
                $buffer = New-Object byte[] 4096
                while ($stream.Read($buffer, 0, $buffer.Length) -gt 0) {}
                $stream.Dispose()
                Write-Host "  OK: $($entry.FullName)" -ForegroundColor Green
            } catch {
                Write-Host "  FAIL: $($entry.FullName) — $($_.Exception.Message)" -ForegroundColor Red
                $errors++
            }
        }
        $zip.Dispose()
    } catch {
        Write-Host "Cannot open archive: $($_.Exception.Message)" -ForegroundColor Red
        return $false
    }
    if ($errors -eq 0) {
        Write-Host "All entries verified." -ForegroundColor Cyan
        return $true
    } else {
        Write-Host "$errors entries failed verification." -ForegroundColor Red
        return $false
    }
}

Test-ZipContents -ArchivePath 'C:\Releases\CratesMod_v1.2.0.zip'

This function reads every compressed byte of every entry, surfacing any data corruption that a structural check alone would miss.

Best practice

Integrate archive verification into every release pipeline. The canonical pipeline sequence is: create archive → verify archive → distribute archive. Distribution should never occur from a pipeline that has not successfully completed the verification step.

Method comparison

Method	Software required	Format support	Automation	Compression options	Best context
Right-click → Send to	None	ZIP only	No	None	Quick one-off distributions
Windows 11 command bar	None	ZIP only	No	None	New users; identical to above
7-Zip right-click	7-Zip	ZIP, 7z, others	No	Full	Most day-to-day archiving
WinRAR	WinRAR	ZIP, RAR, others	No	Full + recovery	RAR with recovery records
PowerShell Compress-Archive	None	ZIP only	Yes	Limited	Automated pipelines
7-Zip command line	7-Zip	ZIP, 7z, others	Yes	Full	Automated pipelines with full control

PowerShell and 7-Zip together cover every archiving scenario encountered in cohort workflows. PowerShell for scriptable ZIP packaging; 7-Zip for full-format support, maximum compression, and password protection.

Archive creation workflow from project start to distribution

Understanding how archive creation fits within the broader project workflow helps clarify when each archiving decision is made and why. The following workflow describes the complete archive lifecycle for a typical 57 Studios™ Unturned™ mod project.

The workflow makes explicit a distinction that new contributors frequently miss: the source archive and the distribution archive are produced from different folder subtrees of the same project, at the same version, for different audiences. They are never interchangeable.

Archive size expectations by project tier

Understanding expected archive sizes at each project tier allows you to plan storage allocation before running an archive operation that may exceed available space.

Project size	Source archive size	Distribution archive size	Snapshot archive size
Small (item-only mod, under 20 items)	50–200 MB	5–30 MB	50–200 MB
Medium (mixed items and vehicles)	200 MB – 1 GB	30–150 MB	200 MB – 1 GB
Large (mixed content + custom map)	1–5 GB	150 MB – 1 GB	1–5 GB
Very large (total conversion)	5–20 GB	500 MB – 3 GB	5–20 GB

The distribution archive is substantially smaller than the source archive because it contains only the compiled Bundles tier and Workshop staging files. The source archive contains the full three-tier asset flow including master Blender files, layered PSD textures, and all reference material.

Did you know?

The ratio between source archive size and distribution archive size is typically 5:1 to 20:1 for Unturned™ mod projects. This large ratio reflects the compression efficiency gained by excluding master source files from the distribution and the fact that compiled Unity3d bundles are already internally compressed. A source archive of 2 GB commonly produces a distribution archive of 100–400 MB.

Extraction verification: confirming recipients can open your archive

Producing a valid archive is only the first half of the distribution responsibility. The second half is confirming that the archive extracts correctly on a recipient workstation. An archive that passes integrity verification but fails extraction due to a path-length issue, a reserved character in a filename, or a ZIP64 compatibility problem has not fulfilled its function.

Extraction testing procedure

Before distributing any archive to external recipients, perform an extraction test on a clean directory:

powershell

# Extract-TestArchive.ps1
# Tests extraction of an archive to a temporary directory and verifies file count.

param(
    [Parameter(Mandatory=$true)]
    [string]$ArchivePath,

    [string]$TestRoot = "$env:TEMP\ArchiveTest"
)

# Clean and create test root
if (Test-Path $TestRoot) { Remove-Item $TestRoot -Recurse -Force }
New-Item -ItemType Directory -Path $TestRoot -Force | Out-Null

$archiveName = [System.IO.Path]::GetFileNameWithoutExtension($ArchivePath)
$extractPath = Join-Path $TestRoot $archiveName

Write-Host "Extracting $ArchivePath to $extractPath..." -ForegroundColor Cyan

try {
    Add-Type -AssemblyName System.IO.Compression.FileSystem
    [System.IO.Compression.ZipFile]::ExtractToDirectory($ArchivePath, $extractPath)
    $fileCount = (Get-ChildItem $extractPath -Recurse -File).Count
    $folderCount = (Get-ChildItem $extractPath -Recurse -Directory).Count
    Write-Host "Extraction successful: $fileCount files, $folderCount folders" -ForegroundColor Green

    # Check for path-length warnings
    $longPaths = Get-ChildItem $extractPath -Recurse | Where-Object { $_.FullName.Length -gt 240 }
    if ($longPaths.Count -gt 0) {
        Write-Host "WARNING: $($longPaths.Count) paths exceed 240 characters — recipients on older systems may have issues" -ForegroundColor Yellow
        $longPaths | Select-Object -First 5 | ForEach-Object { Write-Host "  $($_.FullName.Length) chars: $($_.FullName)" -ForegroundColor Yellow }
    }
} catch {
    Write-Host "Extraction FAILED: $($_.Exception.Message)" -ForegroundColor Red
}

# Clean up
Remove-Item $TestRoot -Recurse -Force
Write-Host "Test complete. Temporary files removed." -ForegroundColor DarkGray

Run this script before every external distribution. An archive that extracts without errors and produces the expected file and folder counts is confirmed ready for distribution.

Best practice

Include the extraction test in the packaging pipeline immediately after the integrity verification step. The complete pipeline sequence is: create archive → verify integrity → test extraction → log result → distribute. An archive that fails extraction testing should be investigated before distribution, not distributed with an assumption that the recipient's environment will handle it differently.

Archive management across a project's lifetime

The archives produced during a project's lifetime accumulate into a historical record of the project's development. Managing this archive collection deliberately preserves the record while preventing uncontrolled storage growth.

The archive inventory

Maintain an archive inventory file in the project's cold-storage folder. The inventory records every archive produced, its purpose, its verification status, and its current storage location.

# CratesMod_archive_inventory.txt
# Archive inventory for CratesMod
# Updated: 2026-05-18

FILENAME                                  | DATE       | TYPE      | VERIFIED | LOCATION
CratesMod_2026-03-01_snapshot.zip         | 2026-03-01 | Snapshot  | OK       | Tier 2: D:\Archives\CratesMod\
CratesMod_2026-03-15_snapshot.zip         | 2026-03-15 | Snapshot  | OK       | Tier 2: D:\Archives\CratesMod\
CratesMod_v0.9.0_source.zip               | 2026-04-01 | Source    | OK       | Tier 2: D:\Archives\CratesMod\
CratesMod_v0.9.0_review.zip               | 2026-04-01 | Review    | OK       | Tier 2: D:\Archives\CratesMod\
CratesMod_v1.0.0_source.zip               | 2026-05-01 | Source    | OK       | Tier 2: D:\Archives\CratesMod\
CratesMod_v1.0.0_workshop.zip             | 2026-05-01 | Workshop  | OK       | Tier 2: D:\Archives\CratesMod\
CratesMod_v1.0.0_source.zip (Tier 3 copy)| 2026-05-01 | Source    | OK       | Tier 3: Google Drive/Archives/

The inventory serves two functions: it allows quick retrieval of any historical archive without searching the storage hierarchy, and it documents the verification status of each archive at the time it was produced. An archive not listed in the inventory should be treated as unverified.

Archive retention and disposal

Not every archive warrants permanent retention. The following retention schedule governs which archives are kept and which are disposed of after their utility period expires.

Archive type	Retention period	Disposal trigger	Disposal method
Snapshot archives (pre-release)	Until project releases	Post-release archival review	Delete after confirming release archive exists
Snapshot archives (post-release)	12 months post-release	Annual archival review	Delete; document in inventory
Source archives (all releases)	Indefinite	Never	Retain permanently
Distribution archives (all releases)	Indefinite	Never	Retain permanently
Review and staging archives	Until review closes	After reviewer confirmation	Delete; document in inventory
Internal scratch archives (numbered experiments)	7 days	Date-based	Delete

Permanent retention applies only to source and distribution archives for released versions. These archives are the evidentiary record of what was shipped and when. Deleting them is not a storage management decision—it is the destruction of a production record.

Common mistake

Applying a blanket "delete archives older than X months" policy without distinguishing release archives from snapshot and scratch archives. A policy that deletes all archives older than 12 months will eventually destroy source archives for early releases. The retention schedule must categorize archives by type before applying any disposal rule.

Batch archive creation for multi-project cohort distributions

When distributing a package that includes assets from multiple mod projects—for example, a cohort bundle release containing contributions from multiple developers—batch archive creation ensures consistency across the constituent packages.

powershell

# New-CohortBundle.ps1
# Creates verified archives for all mod projects in a distribution set.
# Run from the cohort distribution staging folder.

param(
    [Parameter(Mandatory=$true)]
    [string]$BundleVersion,

    [Parameter(Mandatory=$true)]
    [string[]]$ProjectPaths,

    [string]$DestinationFolder = 'C:\Releases\Bundle'
)

Add-Type -AssemblyName System.IO.Compression.FileSystem
$date = Get-Date -Format 'yyyy-MM-dd'
$errors = 0
$log = @()

New-Item -ItemType Directory -Path $DestinationFolder -Force | Out-Null

foreach ($projectPath in $ProjectPaths) {
    $projectName = Split-Path $projectPath -Leaf
    $archiveName = "${projectName}_v${BundleVersion}_workshop.zip"
    $archivePath = Join-Path $DestinationFolder $archiveName
    $bundlesPath = Join-Path $projectPath 'Bundles'

    if (-not (Test-Path $bundlesPath)) {
        Write-Host "SKIP: $projectName — Bundles folder not found at $bundlesPath" -ForegroundColor Yellow
        $log += "$date | $archiveName | SKIPPED (no Bundles folder)"
        continue
    }

    # Create archive
    try {
        Compress-Archive -Path $bundlesPath -DestinationPath $archivePath -Force
        Write-Host "Created: $archiveName" -ForegroundColor Cyan
    } catch {
        Write-Host "FAILED to create: $archiveName — $($_.Exception.Message)" -ForegroundColor Red
        $errors++
        $log += "$date | $archiveName | FAILED (create)"
        continue
    }

    # Verify archive
    try {
        $zip = [System.IO.Compression.ZipFile]::OpenRead($archivePath)
        $count = $zip.Entries.Count
        $zip.Dispose()
        Write-Host "  Verified: $count entries" -ForegroundColor Green
        $log += "$date | $archiveName | OK ($count entries)"
    } catch {
        Write-Host "  Verification FAILED" -ForegroundColor Red
        $errors++
        $log += "$date | $archiveName | FAILED (verify)"
    }
}

# Write bundle log
$bundleLog = Join-Path $DestinationFolder "bundle_v${BundleVersion}_log.txt"
$log | Out-File -FilePath $bundleLog -Encoding utf8
Write-Host ""
Write-Host "Bundle packaging complete. Errors: $errors. Log: $bundleLog" -ForegroundColor $(if ($errors -eq 0) { 'Cyan' } else { 'Red' })

Usage:

powershell

$projects = @(
    'C:\ModProjects\CratesMod',
    'C:\ModProjects\VehiclePack',
    'C:\ModProjects\MapExtension'
)
.\New-CohortBundle.ps1 -BundleVersion '2.0.0' -ProjectPaths $projects

The script processes each project in the list, creates a Bundles-tier archive for each, verifies the archive, and produces a bundle log. A single error does not abort the entire batch—the loop continues and the log records the failure for remediation.

Cohort-recommended practices for mod-source distribution

The following practices are the formal recommendations for archive-based mod-source distribution within the 57 Studios™ cohort.

Practice 1: Always zip the folder, not its contents. When packaging a mod project for distribution, right-click the project folder itself and archive it as a single item. The resulting archive contains the project folder as its root, and extraction produces a clean project folder rather than a flat file dump.

Practice 2: Use the naming convention. Every distribution archive must include the project name and version in the filename, following the ProjectName_vMAJOR.MINOR.PATCH_qualifier.zip pattern.

Practice 3: Verify before distributing. Run Test-ZipIntegrity or the 7-Zip test function on every archive before distributing it. Log the verification result with the archive's filename and the date of verification.

Practice 4: Separate source and distribution archives. A source archive (containing working files, Blender source, PSD files, and the full _Source tier) is a different artifact from a distribution archive (containing only the compiled Bundles tier and Workshop staging files). Never distribute a source archive to public Workshop channels; never submit a distribution archive to internal code review in place of a source archive.

Practice 5: Use AES-256 for any restricted distribution. Any archive containing pre-release content, review materials, or proprietary source data must be AES-256 password protected. The password must be distributed through a separate channel.

Practice 6: Document multi-volume procedures. Any multi-volume archive distribution must include a README.txt file accompanying the volumes, explaining the required extraction procedure and naming all volumes by filename.

Best practice

Maintain a distribution log for each project. The log records the archive filename, the version it contains, the date of creation, the verification result, and the channel through which it was distributed. The log is the audit trail that allows you to answer "what was in the archive we sent to the reviewer on that date?" without re-creating the archive.

Frequently asked questions

Why does my zip file end up larger than the original folder? The source files are likely already compressed. PNG images, compiled Unity3d bundles, and MP3 audio files contain internal compression. A second compression pass on already-compressed data produces an archive the same size or larger than the original due to archive overhead. This is expected behavior. Use the Store (level 0) compression setting when archiving already-compressed files to minimize overhead.

Can I add files to a zip file after it has been created? Yes. In 7-Zip, open the archive (double-click it) and drag new files into the 7-Zip window. In PowerShell, use Compress-Archive -Update. In Windows Explorer, you can drag files directly into a zip folder displayed in File Explorer. However, if the archive has been password-protected in 7-Zip with encrypted filenames, adding new files requires the password.

What is the difference between a zip file and a zip folder? They are the same thing. Windows File Explorer displays a .zip archive as a "compressed (zipped) folder" because it allows navigating the archive's contents in the same interface as a regular folder. The file on disk is a standard ZIP archive regardless of how File Explorer labels it.

Why does 7-Zip open inside File Explorer instead of the 7-Zip interface? Double-clicking a zip file in File Explorer opens it in File Explorer's built-in ZIP viewer by default. To open it in 7-Zip instead, right-click the file and choose 7-Zip → Open archive. To change the default double-click behavior, open Default Apps in Windows Settings and assign 7-Zip as the default application for .zip files.

What is a solid archive and should I use one? A solid archive compresses multiple files together as a single data stream rather than compressing each file independently. This improves compression ratio when files have similar content (such as a folder full of similarly structured text files) but makes it impossible to extract a single entry without decompressing all preceding entries. Use solid archives for archival storage where individual extraction speed is not a concern; avoid solid archives for distributions where recipients may need to extract individual files.

Can I open a 7z file on a computer that doesn't have 7-Zip installed? No. The .7z format is not natively supported by Windows. The recipient must install 7-Zip (free) or another compatible tool such as WinRAR. For external distributions where recipient software is uncertain, use ZIP.

How do I find out what's in a zip file without extracting it? In File Explorer, double-click the .zip file to browse its contents. In 7-Zip, right-click and choose 7-Zip → Open archive. In PowerShell:

powershell

Add-Type -AssemblyName System.IO.Compression.FileSystem
$zip = [System.IO.Compression.ZipFile]::OpenRead('C:\path\to\archive.zip')
$zip.Entries | Select-Object FullName, Length, CompressedLength
$zip.Dispose()

Why does Windows say the zip file is corrupted when I try to open it? Most commonly, the archive was not fully transferred before opening—the file was cut off mid-download or mid-copy. Wait for the transfer to complete before opening. If the transfer is complete and the error persists, the archive may have been corrupted during transmission. Request a fresh copy from the source.

Is AES-256 password protection actually secure? AES-256 is the same encryption standard used by government agencies and financial institutions. The encryption itself is not the weak point. The weak point is almost always the password. A short or predictable password defeats AES-256 regardless of its theoretical strength. Use a randomly generated password of at least sixteen characters. The algorithm is not a substitute for a strong password.

Can I put a zip file inside a zip file? Yes, and it is occasionally useful for organizing a distribution that includes both pre-compressed archives (such as Workshop bundles) and uncompressed source files. However, the inner zip does not gain additional compression—it is stored in the outer zip at its original compressed size. Nested archives are a structural choice, not a compression optimization.

What is the maximum file size I can include in a zip file? The ZIP32 format limits both individual file size and total archive size to 4 GB. The ZIP64 extension removes this limit. Most modern tools (7-Zip, WinRAR, and Windows Vista and later) support ZIP64, but very old tools may not. For archives containing files larger than 4 GB, ensure your tool explicitly uses ZIP64.

Does compressing a zip file again make it smaller? No. A zip file's contents are already compressed. Compressing a zip file produces an archive nearly identical in size to the original zip, plus format overhead. Nested compression of already-compressed data is a common misconception. The outer archive simply stores the zip file at near-original size.

Cross-platform extraction considerations

Mod-source archives distributed to cohort members on different operating systems require additional planning. While ZIP is the universal format, certain archiving decisions that are benign on Windows produce errors on macOS or Linux.

Windows-specific hazards for cross-platform archives

Hazard	Cause	Effect on macOS/Linux	Prevention
Filenames with trailing spaces or periods	Windows allows these; NTFS stores them	Extraction errors or silent truncation	Audit filenames before archiving
Filenames containing `:`, `*`, `?`, `<`, `>`, `\|`, `"`	Windows disallows these in filenames but some tools can create such archive entries	Extraction errors	Never use reserved characters in filenames
Very long paths (>255 bytes)	Windows supports 260+ chars with group policy; most Unix systems cap at 255 bytes per path component	Extraction truncates or errors	Keep path components under 100 characters
Case-insensitive name collisions	`Texture.png` and `texture.png` are the same file on Windows; distinct on Linux	Extraction overwrites one with the other	Use consistent case in all filenames
ADS (Alternate Data Streams)	Windows NTFS streams not visible in ZIP	Silently dropped in extraction	No action needed; ADS data is not relevant to mod content

For distributions that will be extracted on macOS or Linux systems, run the archive through a cross-platform validation check before distribution. 7-Zip's test function surfaces most of these issues.

The macOS __MACOSX artifact

Archives created on macOS include a hidden __MACOSX folder containing resource fork data. When Windows recipients extract such an archive, the __MACOSX folder appears at the archive root alongside the actual content. For cohort distributions where macOS members produce source archives, include a note to creators to use a cleaning tool before distributing. On macOS, ditto -ck --sequesterRsrc produces clean ZIP archives without resource fork artifacts.

Common mistake

Distributing a macOS-created archive that includes the __MACOSX folder without warning Windows recipients. The folder is harmless but confusing—recipients who attempt to navigate into it find only invisible resource fork files. A single-line note in the distribution changelog prevents the confusion.

Best practices summary

Zip the folder itself, not its contents, for project distributions.
Use the ProjectName_vMAJOR.MINOR.PATCH_qualifier.zip naming convention for all distribution archives.
Verify every archive with Test-ZipIntegrity or 7-Zip test before distributing.
Use Deflate (the default) for all external distributions; use LZMA in 7z for maximum-compression internal archives.
Apply AES-256 password protection to all restricted distributions; distribute the password through a separate channel.
Use PowerShell Compress-Archive for automated packaging pipelines.
Separate source archives from distribution archives; never conflate the two.
Include a README.txt with all multi-volume archive distributions.
Store a distribution log recording archive name, version, date, verification result, and distribution channel.
Never use LZMA or Zstd compression inside a ZIP archive intended for external distribution.
For Tebex store item packages, publish a SHA-256 checksum manifest alongside the archive.
Test cross-platform extraction before distributing to recipients on non-Windows systems.
Maintain an archive inventory file in each project's cold-storage folder recording every archive produced, its purpose, its verification status, and its current storage location.

Checksum documentation for archive distributions

For distributions where the integrity chain must be verifiable by a third party—such as Tebex store item packages or Workshop submissions requiring audit trails—a checksum file accompanying the archive provides an independently verifiable record.

powershell

# New-ArchiveChecksums.ps1
# Generates SHA-256 checksums for all zip files in a folder and writes a checksum manifest.

param(
    [string]$FolderPath = (Get-Location).Path,
    [string]$Algorithm = 'SHA256'
)

$checksumFile = Join-Path $FolderPath "checksums_$Algorithm.txt"
$archives = Get-ChildItem -Path $FolderPath -Filter '*.zip' | Sort-Object Name

$results = foreach ($archive in $archives) {
    $hash = (Get-FileHash -Path $archive.FullName -Algorithm $Algorithm).Hash
    "$hash  $($archive.Name)"
    Write-Host "  $($archive.Name): $hash"
}

$results | Out-File -FilePath $checksumFile -Encoding utf8
Write-Host "Checksum manifest written: $checksumFile" -ForegroundColor Green

The resulting checksums_SHA256.txt file contains one line per archive in the standard format (HASH FILENAME), compatible with the sha256sum -c verification tool on Linux and macOS. Windows recipients can verify against it using:

powershell

$hash = (Get-FileHash 'CratesMod_v1.2.0_workshop.zip' -Algorithm SHA256).Hash
$expected = (Select-String 'CratesMod_v1.2.0_workshop.zip' checksums_SHA256.txt).Line.Split('  ')[0]
if ($hash -eq $expected) { Write-Host "Checksum OK" -ForegroundColor Green } else { Write-Host "Checksum MISMATCH" -ForegroundColor Red }

Include the checksum manifest alongside the archive in any distribution where the recipient needs to verify that the file has not been altered in transit.

Best practice

For Tebex store item packages, generate and publish the checksum manifest as part of the release documentation. Buyers who wish to verify the integrity of their downloaded package can do so independently without contacting support. This practice reduces support requests related to suspected file corruption and builds confidence in the distribution pipeline.

Appendix A: PowerShell packaging pipeline for mod-source distribution

The following script implements the complete cohort-recommended mod-source packaging pipeline: archive creation, integrity verification, and distribution log entry.

powershell

# Package-ModSource.ps1
# Creates a verified mod-source distribution archive and logs the result.
# Run from the project root folder.

param(
    [Parameter(Mandatory=$true)]
    [string]$ProjectName,

    [Parameter(Mandatory=$true)]
    [string]$Version,

    [string]$Qualifier = 'source',

    [string]$SourcePath = (Get-Location).Path,

    [string]$DestinationFolder = 'C:\Releases'
)

$date = Get-Date -Format 'yyyy-MM-dd'
$archiveName = "${ProjectName}_v${Version}_${Qualifier}.zip"
$archivePath = Join-Path $DestinationFolder $archiveName
$logPath = Join-Path $DestinationFolder 'distribution-log.txt'

# Ensure destination exists
New-Item -ItemType Directory -Path $DestinationFolder -Force | Out-Null

Write-Host "Packaging $ProjectName v$Version ($Qualifier)..." -ForegroundColor Cyan

# Create archive
try {
    Compress-Archive -Path $SourcePath -DestinationPath $archivePath -Force
    Write-Host "  Created: $archiveName" -ForegroundColor Green
} catch {
    Write-Host "  FAILED to create archive: $($_.Exception.Message)" -ForegroundColor Red
    exit 1
}

# Verify archive
Add-Type -AssemblyName System.IO.Compression.FileSystem
$verifyResult = 'FAILED'
try {
    $zip = [System.IO.Compression.ZipFile]::OpenRead($archivePath)
    $entryCount = $zip.Entries.Count
    $zip.Dispose()
    $verifyResult = "OK ($entryCount entries)"
    Write-Host "  Verified: $verifyResult" -ForegroundColor Green
} catch {
    Write-Host "  Verification FAILED: $($_.Exception.Message)" -ForegroundColor Red
    exit 1
}

# Log entry
$logEntry = "$date | $archiveName | $verifyResult | Source: $SourcePath"
Add-Content -Path $logPath -Value $logEntry
Write-Host "  Logged: $logEntry" -ForegroundColor DarkGray

Write-Host "Packaging complete: $archivePath" -ForegroundColor Cyan

Usage:

powershell

.\Package-ModSource.ps1 -ProjectName 'CratesMod' -Version '1.2.0' -Qualifier 'source'
.\Package-ModSource.ps1 -ProjectName 'CratesMod' -Version '1.2.0' -Qualifier 'workshop' -SourcePath 'C:\ModProjects\CratesMod\Workshop'

The script produces a dated log file in the destination folder. Each entry records the archive name, verification result, and source path. The log accumulates across multiple releases, providing a permanent audit trail.

Appendix B: Archive format interoperability matrix

The following matrix documents the ability of each tool to open each archive format on a stock Windows 11 installation.

Archive format	Windows built-in	7-Zip	WinRAR	macOS built-in	Linux (unzip)
`.zip` (Deflate)	Yes	Yes	Yes	Yes	Yes
`.zip` (LZMA)	No	Yes	Yes	No	Partial
`.zip` (AES-256 encrypted)	No	Yes	Yes	No	No
`.7z`	No	Yes	Yes	No	No
`.rar`	No	Partial (read only)	Yes	No	No
`.tar.gz`	No (Win 11 build 22000+: Yes)	Yes	Yes	Yes	Yes
`.zip` (ZIP64)	Yes	Yes	Yes	Yes	Partial

Use this matrix when selecting an archive format for distribution. Any format in the ZIP row with a "No" in the Windows built-in column cannot be opened by recipients without additional software. For universal compatibility, use ZIP with Deflate compression.

Appendix C: Glossary

Archive. A single file that contains one or more other files, typically in compressed form.
Central directory. The table of contents section of a ZIP archive, listing all entries by name and offset.
Compression algorithm. The mathematical procedure applied to reduce the size of data. Deflate, LZMA, and Zstd are the three algorithms most relevant to mod development.
Compression level. A parameter controlling the trade-off between compression speed and compression ratio within a given algorithm.
Compression ratio. The ratio of the original size to the compressed size. A ratio of 2:1 means the compressed file is half the size of the original.
Deflate. The compression algorithm defined in the ZIP specification; the default algorithm for all Windows-native ZIP archives.
Distribution archive. An archive containing compiled, release-ready assets intended for end users or Workshop upload.
Entropy. A measure of data randomness. High-entropy data (already-compressed files, encrypted files) does not compress further. Low-entropy data (repetitive text, source code) compresses well.
LZMA. Lempel-Ziv-Markov chain Algorithm; the native algorithm of the 7z format; achieves higher ratios than Deflate at the cost of speed.
Multi-volume archive. An archive split across multiple files of a fixed maximum size.
Recovery record. Error-correction data embedded in a RAR archive that allows partial recovery from file corruption.
Solid archive. An archive mode in which multiple files are compressed together as a single data stream for improved ratio at the cost of individual-entry extraction performance.
Source archive. An archive containing working files, master art, and project source data intended for internal review.
ZIP64. An extension to the ZIP format that removes the 4 GB per-file and per-archive size limits.
Zstd. Zstandard; a modern compression algorithm that approaches LZMA ratios at near-Deflate speeds; not natively supported in ZIP format as of 2026.

How to Create a Zip File ​

What you will learn ​

What archive creation actually does ​

Method 1: Right-click → Send to → Compressed (zipped) folder ​

Method 2: Windows 11 native compress (command bar) ​

Method 3: 7-Zip ​

Creating an archive with 7-Zip via right-click ​

7-Zip compression levels ​

Method 4: WinRAR ​

Creating an archive with WinRAR via right-click ​

Method 5: PowerShell Compress-Archive ​

Standard usage ​

Overwriting an existing archive ​

Updating an existing archive ​

Verifying an archive after creation ​

Compression algorithm comparison ​

Deflate ​

LZMA ​

Zstd ​

Archive format comparison ​

Archive naming conventions ​

Convention components ​

Example names ​

Multi-volume archives ​

Creating multi-volume archives with 7-Zip ​

Password protection ​

Password-protecting an archive with 7-Zip ​

Archive integrity verification ​

Verification with 7-Zip ​

Verification with PowerShell ​

Method comparison ​

Archive creation workflow from project start to distribution ​

Archive size expectations by project tier ​

Extraction verification: confirming recipients can open your archive ​

Extraction testing procedure ​

Archive management across a project's lifetime ​

The archive inventory ​

Archive retention and disposal ​

Batch archive creation for multi-project cohort distributions ​

Cohort-recommended practices for mod-source distribution ​

Frequently asked questions ​

Cross-platform extraction considerations ​

Windows-specific hazards for cross-platform archives ​

The macOS __MACOSX artifact ​

Best practices summary ​

Checksum documentation for archive distributions ​

Appendix A: PowerShell packaging pipeline for mod-source distribution ​

Appendix B: Archive format interoperability matrix ​

Appendix C: Glossary ​

How to Create a Zip File

What you will learn

What archive creation actually does

Method 1: Right-click → Send to → Compressed (zipped) folder

Method 2: Windows 11 native compress (command bar)

Method 3: 7-Zip

Creating an archive with 7-Zip via right-click

7-Zip compression levels

Method 4: WinRAR

Creating an archive with WinRAR via right-click

Method 5: PowerShell Compress-Archive

Standard usage

Overwriting an existing archive

Updating an existing archive

Verifying an archive after creation

Compression algorithm comparison

Deflate

LZMA

Zstd

Archive format comparison

Archive naming conventions

Convention components

Example names

Multi-volume archives

Creating multi-volume archives with 7-Zip

Password protection

Password-protecting an archive with 7-Zip

Archive integrity verification

Verification with 7-Zip

Verification with PowerShell

Method comparison

Archive creation workflow from project start to distribution

Archive size expectations by project tier

Extraction verification: confirming recipients can open your archive

Extraction testing procedure

Archive management across a project's lifetime

The archive inventory

Archive retention and disposal

Batch archive creation for multi-project cohort distributions

Cohort-recommended practices for mod-source distribution

Frequently asked questions

Cross-platform extraction considerations

Windows-specific hazards for cross-platform archives

The macOS __MACOSX artifact

Best practices summary

Checksum documentation for archive distributions

Appendix A: PowerShell packaging pipeline for mod-source distribution

Appendix B: Archive format interoperability matrix

Appendix C: Glossary