In this article
This is one possible explanation for storage that seems slow to return after deletion. It is not a diagnosis of every large System Data category, failed deletion or difference between Finder and a storage report. Start by separating those cases.
Check what “deleted” means first
Moving a file to Trash is not the same as removing its last filesystem link. Apple's guide to deleting files and folders explains that items remain available in Trash until it is emptied. Review what you intend to keep before taking that irreversible step.
If Finder showed an error saying a file could not be deleted, do not treat the file as already unlinked. Resolve the error or identify the app using it. That is a different starting point from a filename that has actually disappeared.
| What you observe | A useful next check |
|---|---|
| The item is still in Trash | Decide whether it should be restored or permanently removed. |
| Finder reported that deletion failed | Confirm whether the item still exists and address the reported error. |
| The name is gone, but a known app had the file open | Save work, quit that app normally, and compare the same storage measurement again. |
| No relevant open file is found | Investigate other explanations without assuming the entire Mac has been cleared. |
Normal app controls are the simplest first step for a recognized app. Avoid a force-quit or a broad cleanup command merely because a storage number looks surprising. An app can have unsaved work unrelated to the file you removed.
A filename and an open reference are different
A filesystem name gives software a way to find a file. An app that has already opened the file also holds a reference to it. Removing the name does not necessarily end that reference.
Apple's archived unlink manual describes the relevant condition: when the link count reaches zero while a process still has the file open, removal is delayed until the references close. The missing pathname and the remaining open reference can therefore be true at the same time.
This does not guarantee recovery through Finder, and it is not evidence of malicious behavior. It also does not establish exactly when a storage interface will refresh or how much free space it will display. Those are separate observations.
Inspect a specific process with lsof
If quitting the app is not yet practical, you can inspect it first. In Activity Monitor, select View → All Processes, identify the relevant process and note its PID. A helper can own the file even when the main app does not.
In Terminal, run /usr/sbin/lsof -nP -a -p PID +L1, replacing PID with the current number. The command reads information; it does not remove or close files.
Here, -p selects the process and -a intersects that selection with +L1, which selects files with a link count below one. Look for NLINK equal to 0, along with the process, file descriptor and file type. The upstream lsof FAQ explains this use of +L1 and why reporting names for unlinked files varies by system.
Keep the full relevant row while investigating locally. Filtering only for the word “deleted” can miss the case on a Mac: our test below returned a zero-link file without that suffix.
An empty result means this query found no matching visible entries at that moment. It does not rule out a different process, a different moment or visibility restrictions. Read any warnings, check that the PID is still current, and avoid treating a scoped query as a scan of all possible storage causes.
What the Mac experiment showed
On October 6, 2026, we tested one file created solely for this experiment on macOS 15.7.5. We kept its file descriptor open, inspected its link count, and queried only our own test process. No existing user file was changed.
| Controlled step | Observed result |
|---|---|
| Create and open the temporary file | The pathname existed; link count was 1; the +L1 query found no matching row. |
| Rename it while keeping it open | The new pathname existed; link count remained 1; still no matching row. |
| Unlink the name while keeping it open | The pathname no longer existed; link count was 0; lsof reported the open regular file. |
| Read through the already-open descriptor | The marker written at the start of the file was still readable. |
| Close the descriptor | The process-scoped +L1 query returned no matching rows. |
The rename step was an ordinary rename inside our temporary directory. It was not a simulation of Finder's Trash implementation.
The file contained 4,194,324 logical bytes. Its reported allocation, calculated from the open file's block count, was 4,198,400 bytes both before and immediately after unlinking it. That is direct evidence that removing this name did not immediately remove the allocation while the reference remained open.
We did not measure a corresponding change in the Mac's global free-space display. The test supports the file-lifecycle explanation, not a promise that deleting a file of a particular logical size will increase available storage by that exact amount.
One detail matters when following command recipes: this Mac's lsof row retained a pathname and did not append “(deleted).” Its NLINK 0 value was the useful signal. Other operating systems or versions may format the name differently. We closed the descriptor and removed the temporary test directory at the end.
Stop when the evidence points elsewhere
If there is no relevant open file, do not keep terminating apps until the number changes. Apple's Time Machine local snapshot documentation describes a separate storage mechanism. Its existence does not prove that snapshots explain your particular observation either.
Also compare like with like. A file's logical size, allocated storage and a category shown in a storage interface can answer different questions. The guide to Mac app size in Finder and Storage explains how to keep those scopes distinct.
If your next idea is to delete an app's support folder, first use the Application Support review checklist. Support data may contain work or settings you still need. A folder's name is not proof that everything inside it is expendable.
A before-and-after file comparison can help record path changes, but a missing path does not prove the absence of an open descriptor. Keep the conclusion as narrow as the evidence: confirm what was removed, identify the holder when possible, save work, close the known app normally and repeat the same check. For an unfamiliar process, consult its app documentation before taking action.
Sources behind the checks
- Apple's unlink manual: link counts and open references.
- lsof FAQ: finding unlinked files and interpreting names.
- Apple's Trash guide and Time Machine snapshot guide: separate explanations to check.
