Evidence-backed Windows guide
Replace duplicate files with hard links safely on Windows
Reclaim physical disk space while keeping duplicate paths, with identity checks, crash-safe commits, and a recovery ledger.
Only hard-link byte-identical files on the same NTFS volume. Protect the keeper, create a durable recovery ledger before committing, verify the new link identity, and retain enough data to reconstruct an independent copy during restore.
Check release statusKeyword focus: replace duplicate files with hard links WindowsUnderstand what changes
A hard link is another directory entry for the same NTFS file data. Both paths remain visible, but changing the file through either path changes the shared content.
Use hard links only for exact, same-volume files
Different volumes cannot share an NTFS file record. Similar images, audio, video, folders, archives, or name matches are never hard-link candidates unless the final files are byte-identical.
Require a transactional workflow
The tool should record the source and target identities, create and verify the link, survive interruption, and keep a durable ledger that can restore independent copies.
- Back up the data
- Scan Exact content
- Review the keeper
- Export a cleanup plan
- Replace selected exact copies
- Verify both paths
- Test restore from the ledger
Know when not to use hard links
Avoid them when software expects independent files, when either path may be edited in place, when files cross volumes, or when a simple quarantine is easier to explain and recover.
First-party workflow evidence
Controlled input → mode → expected result → actual result
- Controlled corpus
- The NTFS fixture uses two byte-identical independent files on one volume, an existing hard-linked pair, a same-content file on another volume, and a different file. File IDs, link counts, hashes, paths, and physical-size expectations were recorded first.
- Mode and parameters
- Exact content only. Generate a dry-run ledger, protect the keeper, reject cross-volume and approximate candidates, replace the selected same-volume copy transactionally, verify file identity and link count, then exercise ledger-based restoration to an independent copy.
- Expected result
- Only exact same-volume files are eligible. Existing hard links do not inflate reclaimable bytes. Both paths remain, changes through either path share data, and restore recreates an independent byte-identical file with a different file identity.
- Actual 0.9.0 result
- The frozen engine tests verify same-volume eligibility, hard-link-aware accounting, transactional replacement, durable recovery records, and reconstruction of an independent copy. Cross-volume and non-exact candidates were rejected before mutation.
Failure modes and limits
Hard links are an NTFS storage technique, not a universal duplicate-cleanup mode. They do not cross volumes, can surprise software that edits files in place, and may be unsuitable for sync folders, databases, build outputs, or paths managed by another application.
A scan result can become stale when a file changes after discovery. Revalidate before mutation, close applications that may be writing the files, keep sufficient free space for quarantine or recovery, and treat cloud placeholders as unavailable until they are fully local. A power loss, access-control change, antivirus quarantine, or another process locking a path can interrupt cleanup; the plan and ledger must remain reviewable rather than silently claiming success.
Verify recovery before a large job
Keep a separate backup. After replacement, compare file IDs and hashes, edit neither path during the check, restore one linked path from the ledger, verify the restored file receives independent identity, and confirm that deleting either path no longer affects the other.
Record the input paths, selected mode, application version, result count, proposed reclaimable bytes, and final hashes. That record turns a one-off cleanup into a repeatable procedure and makes it possible to explain why a file was selected. If expected and actual results differ, stop and preserve the exported report instead of compensating with manual bulk deletion.
Bound to one frozen build
These statements use the 353,792-byte executable with SHA-256 5F59977C69A25CCCB9569D1ED3F4F2D8043E2336CCFCD4C14933A623C754D727. The product audit passed; the unsigned distribution gate did not.
Frequently asked questions
Do hard links work across drives?+
No. Windows hard links require the same NTFS volume.
Does deleting one hard link delete the other?+
Deleting one path removes one link. The data remains while another link still references it.
Can a hard link be turned back into a separate copy?+
Yes, if the recovery workflow reads the shared data into a new independent file and verifies the result.
Intent-specific primary sources
This guide combines the frozen product’s public test evidence with the following official or primary technical references. Links were checked August 15, 2026.
Editorial method: claims about UtiliVera are accepted only when tied to the frozen hash and public evidence artifact. Claims about another product are limited to that vendor’s official page. Approximate matches are never described as proof, and the absence of a signed public installer remains visible.
UtiliVera Duplicates
Verify first. Clean second. Recover when needed.
The public download opens after trusted code signing; until then, this page preserves release evidence without starting the 30-day clock.
See the product →