To extract a Windows ZIP named something like Draft[v1].zip, use PowerShell’s Expand-Archive -LiteralPath and specify a separate destination folder. Square brackets can participate in wildcard matching when a command interprets a path as a pattern. A literal path identifies the archive by its actual name; it does not make the archive trustworthy.
This workflow is for unpacking a ZIP you are authorised to handle, not repairing Windows or running its contents. Keep the original archive and existing working files unchanged while you inspect the extracted copy.
Check the archive and choose an unused destination
First reveal the complete filename in File Explorer. The related tutorial on showing full Windows file extensions helps distinguish a ZIP from a differently named download. A familiar icon or name is not evidence that a file is safe.
Open PowerShell normally. Administrator access is not required simply to extract into a location your account can write. Avoid elevated extraction and avoid system folders. The example below uses your Downloads folder; change the archive name to the real ZIP, and choose another destination name if the proposed folder already exists.
$archive = Join-Path $HOME 'Downloads\Draft[v1].zip'
$destination = Join-Path $HOME 'Downloads\Draft-v1-review'
if (-not (Test-Path -LiteralPath $archive -PathType Leaf)) {
throw 'The specified archive file was not found.'
}
if (Test-Path -LiteralPath $destination) {
throw 'Choose a new destination; this path already exists.'
}
Expand-Archive -LiteralPath $archive -DestinationPath $destination -ErrorAction Stop
Get-ChildItem -LiteralPath $destination -Force
The first check confirms a file exists at the specified path. It does not validate its ZIP structure, origin or contents. The second check deliberately refuses both an existing folder and an existing file at the destination. These checks are useful for an ordinary interactive task, but are not a race-free security boundary against another process changing paths between checks.
Understand literal paths and overwrite behaviour
Microsoft’s Expand-Archive documentation gives a bracket-containing archive name as its literal-path example. Single quotes preserve the typed path text in this example; -LiteralPath separately tells the cmdlet not to treat wildcard characters as a pattern. Quoting alone is not a substitute for that parameter.
Microsoft also documents that the destination folder is created if it does not exist. There is no need to pre-create the example folder. By default, Expand-Archive does not overwrite existing files; -Force permits overwrites. This tutorial deliberately omits Force rather than using it as a blanket response to extraction errors.
A separate destination makes review and abandonment easier, but extraction still writes files and consumes storage. It is not a read-only archive listing. If an error occurs, a partial destination may remain. Do not assume the command rolled back everything simply because it stopped.
Inspect the result before opening anything
The final command lists the destination’s immediate children, including hidden entries. It does not recursively verify every nested file, scan for malware or compare the archive against a publisher’s manifest. Inspect the directory structure in File Explorer and check that expected documents are present before using them.
If the archive is intended to contain a report and a data folder, confirm those items rather than treating an error-free extraction as proof of completeness. Do not launch scripts, installers, shortcuts or executable files merely to see whether extraction worked. Follow your organisation’s download and malware-scanning process for unfamiliar material.
Handle errors without merging folders
- Archive not found: check the exact filename, download location and whether the download completed. Do not rename an unrelated file to ZIP.
- Destination already exists: inspect it and choose a fresh review folder instead of adding Force.
- Extraction fails: preserve the error and original archive. Check permissions, available storage and format support. This cmdlet supports ZIP archives, not every compressed format.
- Names look wrong: the Microsoft documentation notes that archive filename encoding can affect extracted names. Check with the sender instead of silently renaming evidence.
FAQ and finishing checklist
Does a successful extraction prove the download is authentic? No. Extraction is not signature verification or publisher authentication. Can I delete the original immediately? Keep it until the extracted content has been checked and your retention requirements are satisfied.
Before finishing, record the archive path, destination and any extraction error. If abandoning the test, identify the newly created review folder carefully and remove only that disposable copy through your normal file-management process; leave the original and existing work alone.
Educational use only. Test carefully before production. The site owner is not responsible for misuse, damage, data loss or production issues.
