- Freeze the starting state
- Define the cleanup question
- Screen duplicate candidates
- Verify content
- Preview names and collisions
- Export before acting
Why cleanup begins with a manifest
A folder cleanup usually starts when storage is tight or a directory has become hard to navigate. That urgency encourages the most dangerous sequence: sort by size, select a large batch, and delete whatever appears redundant. The problem is that a file list is not yet evidence. A filename can be misleading, copies can have different dates, and two unrelated exports can have the same byte length.
A safer workflow creates a fixed record of the starting state before any destructive action. The record should include relative paths, byte sizes, and dates. It should be exportable and kept outside the folder being cleaned. That manifest cannot restore deleted bytes, but it gives you a reference for investigating what changed and for matching a backup against the original structure.
1. Freeze the starting state
Choose the target folder in the File Audit Lab and export both CSV and JSON. CSV is convenient for filtering in a spreadsheet. JSON preserves field names and is easier to process with a script later. Store both exports in a separate location, ideally alongside a real backup.
Record the date, device, selected top-level folder, and intended scope. “Downloads folder on laptop” is better than nothing, but “Downloads folder, excluding the active tax return subfolder, before moving media to external storage” is a decision record. Scope prevents a cleanup from gradually expanding into folders that were never backed up.
2. Define the cleanup question
Do not combine every goal into one pass. A duplicate review asks whether bytes repeat. A naming review asks whether paths are understandable and portable. An archive review asks whether a file is still needed. Those questions use different evidence and have different failure costs.
| Goal | Useful evidence | Evidence that is insufficient alone |
|---|---|---|
| Recover duplicate storage | Same size, matching SHA-256, manual choice of retained copy | Similar filename or thumbnail |
| Standardize names | Full proposed path, collision report, reversible mapping | A clean-looking sample of ten names |
| Archive old material | Project context, backup, owner decision | Modification date alone |
3. Screen duplicate candidates
Open the duplicate section and review same-size groups. A size group is a work queue, not a deletion list. Large groups deserve attention because they can recover more space, but group size says nothing about which location is authoritative. A copy in an archive may be the one you intended to preserve.
Exclude obvious cases before hashing. Empty files, generated caches, and deliberately duplicated templates may not justify further review. The tool already excludes zero-byte files from candidate grouping because unrelated empty placeholders naturally share the same size.
4. Verify content
Run SHA-256 verification only after candidate screening. Matching digests are strong evidence that the file bytes are identical. They do not compare folder permissions, cloud history, external metadata, or whether another application depends on a particular path.
For each confirmed group, decide on a retention rule in advance: keep the copy in the canonical project folder, keep the copy with the clearest surrounding context, or move all but one copy into a quarantine folder for a fixed review period. Quarantine is slower than immediate deletion but gives you a recovery path that does not depend on a recycle bin.
5. Preview names and collisions
Run the rename preview separately from the duplicate review. Lowercasing and replacing spaces can cause two distinct names to converge. Unicode normalization and punctuation removal create less obvious conflicts. Review collisions at the full relative-path level; the same filename is harmless in two folders until a later flattening or sync operation combines them.
Do not resolve every collision by appending an automatic number. A collision can reveal two versions that need a human label such as a date, language, approval state, or source. Numbers hide that distinction.
6. Export before acting
Download the final inventory and rename map. The map should contain original path, proposed path, whether the name changes, and whether a collision exists. Perform the actual cleanup with a separate, trusted process after backing up the folder. Work in small batches and compare the result with the exported plan after each batch.