The scanning half of a storage tool is low-stakes: read some metadata, draw a picture, done. The cleanup half is where a badly designed tool can actually cost you something. This article is a framework for evaluating cleanup safety specifically — the part of any storage tool's design that deserves the most scrutiny before you rely on it.
Trash versus permanent deletion
The single most consequential design decision in any cleanup feature is whether it moves files to the Trash or deletes them outright. These are not interchangeable with a minor difference in convenience — they represent two entirely different risk profiles.
Trash-based deletion is recoverable. If a tool moves something to Trash that you didn't mean to remove, you can restore it in seconds, as long as you haven't separately emptied the Trash. Permanent deletion (sometimes implemented via a direct filesystem unlink rather than a Finder-style move) has no such recovery path — once it's done, the only way back is a backup, if one exists and is current.
Given that a storage tool's whole purpose is to identify things you might not have looked at in months or years, the case for permanent deletion as a default is weak. Even command-line tools like ncdu, which do delete directly rather than moving to Trash, are typically used by people who understand exactly what they're pressing and why. A GUI tool aimed at a broader audience should default to something recoverable.
What re-validation means and why it matters
A storage tool builds its picture of your disk from a scan that happened at some point in the past — maybe seconds ago, maybe an hour ago if you left the window open. Between that scan and the moment you click "move to trash," anything could have changed: you might have already deleted the file elsewhere, another app might have modified it, or (in rare but real cases) a file could have been replaced by something else entirely at the same path.
A careful cleanup implementation re-checks each item immediately before acting on it — confirming the file still exists, still looks like what the scan found, and is still within the scope you approved — rather than blindly acting on a snapshot that might be stale. This matters most when a scan window has been open a while, or when a cleanup covers many items at once and takes more than an instant to execute.
Ask, when evaluating a tool: if I delete a file in Finder after a scan completes but before I confirm cleanup in the tool, does the tool notice? A tool that would try to act on a file that's already gone (or silently succeed at nothing while reporting success) has skipped a validation step that matters.
The itemised list versus the single number
There's a meaningful difference between a cleanup interface that shows you "3.2GB will be freed" with a single confirm button, and one that shows you the actual list of files and folders that make up that 3.2GB, with the ability to deselect individual items before confirming.
The single-number version asks you to trust a category label ("junk files," "cache," "large files") without seeing what's actually in it. The itemised version lets you catch a false positive — a "cache" folder that turns out to contain something you actually wanted — before it's too late rather than after.
Paths a careful tool should refuse to touch, or handle with extra caution
Not every path on disk is equally safe to offer up for deletion, even inside a legitimate cleanup workflow. A few categories deserve specific caution:
- Symlinks — following a symlink during a recursive cleanup operation can lead a tool to affect files well outside the folder you intended to clean. A careful tool does not follow symlinks by default during destructive operations.
- System and protected paths — regardless of what a tool's own logic decides, macOS's System Integrity Protection blocks writes to certain system directories outright. A tool that tries to work around this rather than respecting it is not a tool you want near your disk.
- Anything currently open or in use — a file actively held open by a running process behaves unpredictably if deleted mid-use. This is a smaller concern for a storage tool that scans and lets you review before acting, since some time typically passes between scan and action, but it's still worth a tool checking rather than assuming.
What happens after Trash, and why that step matters too
A Trash-based cleanup is only as safe as the Trash itself, which is worth thinking through as part of the same evaluation. Some Macs are configured (either by the user, or by a tool's own recommended setting, or by the built-in Storage Recommendations panel) to automatically empty Trash items older than 30 days. That's a reasonable default for most people, but it means "moved to Trash" and "recoverable indefinitely" are not quite the same guarantee — there's a window, not a permanent safety net.
A cleanup tool doesn't control what your Finder-level Trash settings are, and it shouldn't try to override them. But it's worth knowing your own configuration: if you have automatic Trash emptying turned on, a cleanup you approved today is genuinely gone in 30 days whether or not you separately confirmed it. That's still a meaningfully safer default than immediate permanent deletion, since it gives you a real window to notice a mistake, but it's not an unlimited one.
Why undo is not the same as Trash
Some apps offer an in-app "undo" for a cleanup action, separate from the Trash mechanism. This can be convenient, but it's worth understanding what it actually does before relying on it instead of checking the Trash directly — an in-app undo that only works within the same session, or only before you quit the app, is a narrower guarantee than Trash, which persists across app launches and system restarts until you explicitly empty it or your automatic-empty setting kicks in. Trash is the more durable safety net of the two, and a tool's in-app undo, where offered, should be treated as a bonus convenience layered on top of Trash rather than a substitute for it.
A short evaluation checklist
| Question | What you want to hear |
|---|---|
| Trash or permanent delete? | Trash, always |
| Confirmation before acting? | Yes, with an itemised list, not just a total |
| Re-checked at the moment of action? | Yes |
| Symlinks followed during cleanup? | No, never by default |
| Admin password required? | No, for a tool that only touches your own files |
| Protected system paths touchable? | No — SIP should apply, and the tool should respect it rather than attempt to bypass it |
Where VolumeLens fits
Move to Trash is the only cleanup action VolumeLens offers — there is no permanent-delete path in the app at all. Every cleanup shows an itemised review sheet before anything happens, and each item is re-checked at the moment you confirm, not just at scan time. The app runs in the App Sandbox with no privileged helper and never asks for an admin password, and it does not follow symlinks by default. None of this makes cleanup risk-free — nothing involving deleting files can be — but it's designed so the risk you're taking is small, visible, and recoverable. You can see the full review workflow on the features page or download VolumeLens and try it on a folder you already know well, to see exactly what the review sheet shows before anything moves.