What actually happens after a duplicate is deleted

Most advice about duplicate files stops at the moment of deletion, as though everything after that is automatic. It is not. Removing one of two identical looking files can free the expected space and change nothing else, or it can break a link in a project that has not been opened for a month, or it can remove the same file from a phone in someone else's pocket. Which of those happens is determined by two things that a duplicate scanner does not report: how the file is attached to the rest of the system, and which volume it sits on.

Three attachments that survive their own deletion

Two entries that look like copies are not necessarily two files. There are three arrangements where deleting one of them leaves the data exactly where it was.

An alias is a small record pointing at a target. Deleting the alias removes the pointer and nothing else. Deleting the target leaves the alias behind, although macOS aliases track their target through moves and renames, so they survive far more disruption than the path-based alternative.

A symbolic link behaves the same way from the storage side and worse from the resilience side, because it stores a path rather than a reference to the file itself. Move the target and the link goes stale even though nothing was deleted.

A hard link is the one that surprises people. Two names refer to one set of data, both are equally real, and removing either one leaves the other completely intact. No space is returned until the last name is gone.

All three share a property worth stating plainly: deleting them frees nothing. A cleanup session that ends with unchanged free space very often ended with pointers removed rather than data. The check takes one command.

ls -li big.bin hard.bin
513570627 -rw-------  2 admin  wheel  20971520 Sep  5 13:24 big.bin
513570627 -rw-------  2 admin  wheel  20971520 Sep  5 13:24 hard.bin

The leading number identifies the underlying data. Matching numbers mean one file with two names. The digit after the permissions column is the count of names pointing at it, and the data persists until that count reaches zero. In Finder, all three arrangements are drawn exactly like ordinary files.

Deletion inside a synced folder is not a local action

Location changes the stakes more than attachment does. With Desktop and Documents stored in iCloud, removing a duplicate is not an operation on one machine.

Important: When you delete a file from iCloud Drive on iCloud.com, it's also deleted from all your devices that have iCloud Drive turned on. Source: support.apple.com

The relationship runs both ways and applies to every sync product, not just Apple's. Delete on the Mac and the file leaves the phone. Delete inside a shared folder and it leaves the collaborators' machines too, including the one who is working in that file right now. A tidy-up that felt like housekeeping becomes an interruption on somebody else's schedule.

Checking before deleting is a matter of noticing which folder the file lives in. Pausing sync during a cleanup is possible but introduces a second problem, because edits made elsewhere while it is paused arrive as conflicts afterwards. For shared folders, asking first is genuinely faster than resolving what follows.

Bundles that look like folders

Photos and Music libraries present as folders and are not. The application maintains its own index mapping entries to files on disk, and a duplicate scanner pointed at the library will report large numbers of matches: originals next to edited versions, thumbnails, cached renditions, exported copies. Very few of them are redundant in the sense the scanner implies.

Deleting inside such a bundle from Finder or the shell removes the data while the application's index continues to list the entry. Nothing fails at the moment of deletion. The failure appears later, when the item is opened, at which point the cause is a cleanup nobody remembers performing. Consolidating duplicates through the application's own tools avoids the mismatch entirely.

The same shape applies to mail attachments and message data inside application support folders. Several copies of one attachment usually means several messages carrying the same file, which is redundancy the mail client depends on rather than waste.

A practical way to recognise these: double-click the item in Finder. If an application opens instead of a folder window, it is a managed container, and it belongs on the exclusion list of any scanning tool before the first scan runs.

Space returns when the last process lets go

A deletion that produces no change in free space is usually not a failed deletion. If a running program still holds the file open, removing the name does not release the storage.

The behaviour is easy to observe. Delete a 300 MB file while a process has it open, and free space does not move. When that process exits, roughly 290 MB comes back at once. Video exports, editors holding a large log, and applications with an open database all produce this, and it is the reason that cleanup advice so often ends with a reboot: restarting resolves every instance of it at the same time, without needing to identify any of them.

Identifying them takes one command.

sudo lsof +L1

Each line is data still occupying the disk with no name left in any directory. Quitting the listed application returns the space immediately, which is a smaller intervention than a restart when the work in progress cannot be interrupted. Temporary files created during an export show up here too, so measuring after closing the active applications gives a truer number.

How long the undo lasts depends on the route

Reversibility is not a single answer. Each deletion path has its own window.

Route	Recovery	Window closes when
Finder to Trash	Put Back restores the original location	the Trash is emptied
rm in a terminal	no standard mechanism	the command returns
File in iCloud Drive	Recently Deleted	30 days pass
Photos library	the app's own Recently Deleted	the same period elapses
Any file with a backup	restore from the backup	anything created since the last snapshot

Apple states the iCloud window explicitly.

Files you delete from iCloud Drive are recoverable for 30 days, but you can remove deleted files before the 30-day time period is up. Source: support.apple.com

Row two is the one that catches people automating a cleanup. rm has no Trash equivalent, so a scripted rule that misclassifies one file destroys it on the spot. A cleanup script that moves candidates into a holding folder instead, leaving the actual deletion as a separate manual step after review, keeps the same speed and adds a checkpoint where mistakes are still cheap.

Volumes where the Trash does not exist

The same Trash operation behaves differently depending on the volume underneath it. On the internal disk, and on writable external disks, deleted items move to a hidden folder on that same volume. That is why an external drive shows no extra free space until the Trash is emptied while it is still connected.

Network volumes are the exception that costs people files. A mounted share generally has no Trash for macOS to use, so the operation presents a confirmation and then removes the item permanently. Cleaning up duplicates on a company file server or a NAS sits in exactly this category, and the mental model of "recover it from the Trash later" has nothing behind it.

Read-only mounts fail in the opposite direction and cannot delete at all. Disk images left mounted and backup volumes both produce this. When a deletion is refused, checking which volume is in view resolves it faster than investigating permissions.

Counting what points at the file

Everything above leads to one conclusion: the decision does not depend on whether the contents match. It depends on what refers to the file. Three commands cover the common references.

find ~/work -type l -lname '*artwork.psd*'
grep -rl "artwork.psd" ~/work
lsof "/Users/you/work/artwork.psd"

The first finds symbolic links naming the file. The second finds documents, configuration, and code containing the path, which is how web assets, video project files, and manuscripts refer to their images. The third reports whether anything currently has it open.

Three empty results mean nothing local breaks. A non-empty second result is the one to read carefully, because a relative path written inside a project file breaks the moment the target is renamed or moved, not only when it is deleted.

Recording those counts pays off later. Adding a reference count column to the list of deletion candidates turns an unordered pile into a queue, with the zero-reference rows first and the risky ones visible. Months afterwards, that same list answers the question of what was removed, which is the part of a cleanup that people actually regret losing.

The checks worth running once the deletion is done

Three verifications catch nearly everything that goes wrong, and all three are cheap on the day of the cleanup and expensive a month later.

Measure the free space again, after quitting the applications that were open during the work. A number that has not moved says the removed entries were pointers, or that something still holds the data open, and both have been covered above. A number that moved by far more than expected is worth investigating too, since it can mean the selection reached further than intended.

Open one project from each category that touched the deleted files. A video project, a page layout, a repository that was checked out. Applications resolve their references at open time, so a broken path stays invisible until then, and finding it while the reference list is still on screen makes the fix a lookup rather than an investigation.

Let sync finish before disconnecting or sleeping the machine. A cleanup of several thousand files produces a long queue of deletions to propagate, and interrupting it midway leaves devices in different states. The menu bar indicator showing the sync as complete is the signal that the operation actually ended.

Beyond that, keep the candidate list. It costs nothing to store a text file and it converts every future question about a missing file from a search into a lookup. Cleanups that go badly are rarely the ones that deleted the wrong file. They are the ones where nobody can reconstruct what was deleted at all, so every subsequent problem gets blamed on the cleanup whether or not it caused them.

What to change first

Assembling those three answers currently means three surfaces: the scanner's list, a terminal for the reference counts, and a preview to confirm the files really are interchangeable. The judgement takes seconds. Gathering the material for it takes the rest of the afternoon once the candidate list passes a hundred rows.

Before adding another scanning tool, count the window switches for one real cleanup. If that number is the bottleneck, the useful comparison is arrangement rather than features, which is the axis used throughout the comparison with other file managers and the reasoning behind the single window described under Features. Atriens is built on that arrangement.