A report listing 133.03GB of duplicate data did not mean that much space could be cleared. The next questions were whether a program needed a path, which copy to retain and whether several names referred to the same stored file.
An earlier work chat contains a request to find cleanup candidates and the resulting investigation. I read the archived report dated 2026-10-28 and its aggregation code. The priority candidates totalled 45.43GB, which was also an estimate rather than space observed after deletion.
Duplicate totals and priority candidates are different lists
The duplicate investigation identified 998 groups with matching content. Its 133.03GB total adds the remaining copy sizes after hypothetically keeping one copy per group. That total leaves open whether an original or a running program needs a particular path.
The 45.43GB priority list separately selects package caches, temporary archives with a verified retained counterpart and older temporary material meeting stated conditions. Some entries overlap the duplicate list. Adding the totals would count files again, while subtracting them would not identify duplicate bytes still awaiting cleanup. The selection rules differ.
For this article I summed the archived priority CSV bytes and compared them with the saved JSON total. Their agreement verifies arithmetic in that record, not a fresh disk investigation or an observed increase in free space. GB uses one billion bytes.
Size and sample equality only narrow the candidates
The inspected comparison code selects candidates from files of at least 16MiB and groups them by size. Samples from several positions narrow the candidates before a full SHA-256 comparison. Sampling reduces the amount of data to read; it does not replace the final content comparison.
Some full hashes were reused from an earlier investigation after checking file ID, size and nanosecond modification time against the current metadata. Paths read afresh also undergo checks for changes after inventory. The report should therefore not be described as rereading every file in full on every pass.
Sensitive and protected material, inaccessible files and other exceptions define the investigation’s limits. Matching content describes the candidates that passed those comparisons. It neither gives every file on the computer the same depth of inspection nor certifies that the contents remain identical today.
Several paths can represent the same stored file
Traversing a storage device again through an alias can count the same material twice. The archived report treats an alias that looked like another drive as part of its original volume and avoids scanning it again. Path count and storage-unit count need separate meanings.
An NTFS hard link allows several paths to refer to one file within the same volume, as Microsoft’s documentation explains. The inspected aggregation separately groups aliases by volume and file ID. Multiple names do not become multiple independent copy sizes.
The detailed cache audit compares observed aliases with the link count. Units with links outside the target scope are excluded from the reclaim estimate. That is a condition of the inspected calculation, not a guarantee that summed file sizes equal allocated space. Compression, allocation units and concurrent work can also affect the observed difference.
Source: Microsoft Learn, Hard Links and Junctions.
The official explanation of multiple same-volume paths referring to one file.
Choose a retained path after comparing contents
Equal hashes do not make originals, installed programs, models and recovery copies serve the same role. The report code protects flagged storage units and separately chooses a reference-copy candidate. Each row retains a keep path and a preservation or unresolved-use reason.
The ranking uses protection flags, path categories and modification times; it cannot decide which copy is the business’s authoritative original. Entries with unknown program references remain on hold. Equal contents in another folder do not make a program start using that new path.
The same question arises when a website attachment leaves the current page but older documents or backups still need it. The existing reference-retention example helps explain that decision. Its relationship metadata does not inspect this PC’s files or hard links.
Separate package caches from installed environments
The priority list names package download and build caches. It does not include clearing installed project environments, models and credentials along with them. The conditions also require installation or update work to have finished. A cache-named directory does not extend the cleanup scope to its neighbours.
Temporary verification archives become candidates after comparison with a retained archive at another location using full hashes. The candidate row preserves that location and evidence. This differs from deleting the final recovery copy merely because its folder is labelled temporary.
The investigation report explicitly records no deletion or movement. Other cleanup completions in the same chat belong to their own times and evidence. Copy comparison, candidate review, actual removal and a later free-space measurement should retain those distinctions.
Leave enough detail for the next review
Keep the following beside each capacity estimate. This guidance comes from the archived investigation; it is not a new cleanup tool or an execution result.
I wrote this article by reading reports and sources without running the original inventory, hashing or cleanup scripts. I did not re-establish current file uses or recovery readiness. A later cleanup plan needs a defined scope and retained copies. The next review can check whether the retained path is usable, whether an active path entered the candidate list and whether an item was counted twice.
- Identity evidence: the full hash, observation time and any conditions used to reuse an older hash.
- Storage identity: volume, file ID and links, including aliases outside the target scope.
- Retention: the path to keep, its role and any uses still unknown.
- Accounting: overlap with other lists and the difference between summed bytes and a reclaim estimate.
- Execution state: whether only investigation occurred, whether removal happened separately and when actual space was measured.