Duplicate-file cleanup becomes risky when a tool jumps directly from “these names look alike” to deletion. A safer process inventories first, identifies byte-for-byte matches, preserves errors, and leaves the final cleanup decision to a person who understands the folders.
Do not use filenames as proof of duplication
Two files can have the same name and different contents. The same file can also appear under different names. File size is a useful screening field, but equal size alone does not prove equality. A cryptographic hash such as SHA-256 provides a much stronger comparison: files with the same byte content produce the same hash value.
Inventory before changing anything
For each file, record its relative path, filename, extension, byte size, modified timestamp, and SHA-256 value. Preserve files that cannot be read as explicit error rows instead of silently excluding them. An error may indicate permissions, a broken link, a locked file, or a path problem that needs separate review.
Group exact matches, then inspect context
Group files only when their hashes and byte sizes match. Within each group, compare the folder locations, filenames, timestamps, and the reason each copy may exist. A byte-for-byte duplicate in a backup folder may be intentional. A duplicate inside two active project folders may have different retention requirements even though its content is identical.
Choose a keeper rule before cleanup
A keeper rule might prefer an authoritative project folder, the location covered by a backup, the copy with clearer surrounding documentation, or the source package that must remain unchanged. Do not automatically prefer the newest timestamp: copying a file can change timestamps without changing the document’s origin or importance.
- Protect system, application, cloud-sync, and backup folders from casual cleanup.
- Keep original evidence or delivery packages intact.
- Verify a separate backup before large cleanup actions.
- Move a small review batch before considering permanent deletion.
Use reports that remain reviewable
An HTML report is useful for browsing duplicate groups, while CSV supports filtering and sorting and JSON provides a machine-readable record. Keep the inventory with its generation time, selected root folder, hash algorithm, file count, byte total, and error count.
Understand what SHA-256 does not prove
A matching SHA-256 value is strong evidence that the compared file bytes are identical. It does not prove authorship, authenticity, ownership, retention authority, or that deleting one location is safe. Those questions depend on provenance, context, backups, and the purpose of each folder.
Make cleanup a separate, deliberate phase
After reviewing duplicate groups, create a proposed-action list with keeper path, candidate path, reason, backup status, and reviewer decision. Execute a small reversible batch and verify the result before expanding. A duplicate finder should help you make informed decisions; it should not make irreversible decisions for you.