重複ファイルの整理 not working: what to check, in order

The scan has been running for five hours and the progress bar has not moved since lunch. Or it finished, thousands of files went to the Trash, and the free space number is exactly where it was. Or the whole thing worked, and the deleted copies were back the next morning. Searching for 重複ファイルの整理 fuguai usually means one of those three, and in almost every case the tool is behaving correctly. What has gone wrong sits underneath it: a folder whose contents are not really on the disk, a permission that was never granted, a second service watching the same directory. The checks below are ordered from cheapest to most expensive, which matters when the expensive one takes six hours.

Shrink the scope before changing any setting

The first move is not a setting. It is to stop scanning the whole disk.

Running against an entire volume produces several failures at once, and they mask each other. A permission problem makes part of the result empty, a cloud folder makes the run slow, and a development directory fills the list with files that were never duplicates. All three arrive in the same result set, so nothing can be attributed to anything.

Point the next run at a single folder whose contents you can describe from memory. Downloads is the usual choice, since it is large enough to reproduce the symptom and disposable enough that a mistake costs nothing. Run in report only mode, so the output is a list rather than an action.

If the symptom disappears at that scope, the fault is in something the wider scan touched, and the next step is adding folders back one at a time until it returns. If the symptom persists on a small local folder, the cause is close to hand: permissions, the detection method, or the tool itself.

Symptom	Where the cause usually lives	Cheapest check
Scan never finishes	Cloud placeholder files, sleeping volumes	Look for cloud icons in the folder
Folders return no results	Privacy permissions	Open the Full Disk Access list
Free space unchanged	Trash, snapshots, APFS clones	Empty the Trash, then recheck
Deleted copies reappear	A second sync service	Count what watches that folder
Unrelated files listed	Name or size matching, bundles	Switch to content based matching

The scan never finishes

The most common cause is that the files being scanned are not on the Mac. With storage optimisation enabled, a cloud folder can list thousands of items whose bodies live remotely. Any content based comparison has to read those bytes, so the scanner triggers a download of everything it touches.

Nothing about that looks like a download. It looks like a scanner that has hung. Open the folder in Finder and look for cloud icons next to the filenames. If most of the folder is offloaded, either exclude it or download it deliberately before scanning, and expect the download to take as long as the connection requires.

The second cause is a volume that goes to sleep. Network shares and bus powered drives can drop mid read, and many tools wait rather than fail, so the run sits at ninety percent forever. Test with a wired local folder only. A clean finish there means the problem is the connection, not the software.

The third possibility is simply scale. Hashing every file on a multi terabyte archive is hours of sustained reading no matter which product is doing it. Tools that prefilter by size before hashing finish dramatically sooner on large sets, because most files have a unique size and never need to be read at all. If the product does not describe its method, treat a long first run as expected rather than broken.

Whole folders come back empty

A result set with visible holes in it, or a terminal run printing Operation not permitted, is a permissions problem rather than a detection problem. macOS gates access to the Desktop, Documents, Downloads, photo libraries, and mail storage on a per application basis.

Open System Settings, go to Privacy and Security, and look at Full Disk Access. The application doing the scanning has to be listed and enabled there. If the scan runs from a shell, the terminal application is the one that needs the entitlement, not the command being typed.

Permissions are read when an application starts, so granting access to a running app changes nothing until it is quit and reopened. That single detail accounts for a large share of reports that the setting did not help.

The execution path matters as well. A scan that returns full results when launched by hand can return nothing when the same job is registered as a scheduled task, because background jobs run under a different context and may not inherit the permission that was granted to the interactive application. Anyone planning to run the cleanup on a schedule should verify the output of the scheduled run itself, not the manual test that preceded it.

A second category is files owned by another user account, which arrive through shared folders or a migration from an older Mac. These produce partial results and failed deletions rather than a clean error. A tool that reports how many operations failed, and why, makes this visible immediately. One that reports only successes leaves you comparing counts by hand. Requirements of this kind are usually documented rather than guessed at, and a vendor FAQ is the normal place to find which permissions a given tool expects before it will see everything.

The space does not come back

Three causes, checked in this order.

The Trash is first. Most tools move rather than delete, and items in the Trash still occupy the volume they came from. Nothing changes until it is emptied.

Snapshots are second. When the backup destination is disconnected, Time Machine keeps local snapshots on the internal disk, and files deleted since the last snapshot still exist inside it. Space returns when those snapshots age out or when a backup runs against the real destination. The delay is normal and not a sign of failure.

The third cause changes the premise of the whole exercise. On APFS, a file copied within the same volume is a clone: the two paths share their data blocks until one of them is written to. Two visible files, one file worth of disk. A scanner reports them as duplicates because their contents are identical, and they are, but deleting one frees close to nothing.

If the goal was reclaiming space and most results turn out to be clones, duplicate removal is the wrong lever entirely. The disk is being consumed by large single files, and the fastest way to see which ones is to sort the volume by size rather than by similarity.

The copies come back

Deleted at night, present in the morning, is a synchronisation symptom. Two services watching the same directory will restore each other's deletions, because to the second service the removal looks like a change that its own copy has not received yet.

The same overlap also manufactures duplicates. When two sync clients both write to a folder, one of them treats the other's update as a conflict and writes a second file with a marker appended to the name. That is a duplicate generator running continuously, and cleaning up against it is work that undoes itself within weeks.

Before deleting anything again, count what watches the folder. Apple's own guidance is to disable other third party sync services on folders that iCloud Drive is syncing, precisely because the two sets of updates interfere.

Other devices count as well. A phone or tablet signed into the same account can hold the pre deletion state and push it back. If the same documents are handled from more than one device, read how the product expects that to work, since behaviour varies: some treat the desktop as authoritative, others sync both directions. Vendors that support mobile continuation normally state which model they follow.

The list is full of files that are not duplicates

Unrelated files in the results mean matching is running on names or sizes. Camera numbering collides across devices, and exported documents land on identical byte counts often enough to fill a list with coincidences. Switch to content based matching if the tool offers it.

If unrelated files persist afterwards, the scope is the problem. Application bundles, dependency directories, asset libraries, and virtual machine images all contain repeated files as part of their structure. Those files are identical and are supposed to be. Deleting one side breaks the thing that owns them, so these paths belong in the exclusion list permanently rather than being reviewed row by row.

Symbolic links and aliases are a related trap. They are references to a file rather than copies of it, but a scanner set to follow them will read the target and count the same body twice. Deleting one side then removes the real file and leaves a reference pointing at nothing, which looks like corruption rather than like a deletion. Entries with implausibly small sizes, or several rows resolving to one path, are the signal to turn link following off and rerun.

The opposite failure is quieter. Files that are obviously the same never appear as candidates, usually because Japanese filenames can be stored in two different normalisation forms. The characters render identically while the byte sequences differ, so name based comparison treats them as unrelated. This shows up on files that arrived from external drives, from Windows machines, or from older archives. Content based matching sidesteps it, which is another reason to prefer it. How each product handles these cases is worth reading in a comparison of file managers rather than discovering mid cleanup.

Recovering something that should not have gone

Check the Trash first. Unless the setting was changed, most tools move files there, and restoring puts them back where they were.

If the Trash is empty, use Time Machine. Open the folder the file belonged to, open Time Machine, move back through the snapshots until the file appears, and restore it. Restored items return to their original location, so knowing which folder it lived in is enough to find it.

If neither route works, the deletion log is what remains. A log that records source paths makes it possible to check whether another copy survives elsewhere, on an archive drive or a second machine. Without one, there is no way to distinguish a file that was deleted from a file that never existed, which is the argument for enabling logging before the first destructive run rather than after the first accident.

What to change first

Run the next scan against one backed up folder, in report only mode, with content based matching and an exclusion list that covers application bundles and development directories. That single run separates the five symptoms above from each other in minutes instead of hours.

Then fix the source rather than the symptom. If the cause was overlapping sync, reduce the folder to one watcher. If it was scope, save the exclusion list so the next run starts correct. Tools that keep scope, exclusions, and logs as saved configuration, such as Atriens, are the ones where that fix survives into the next cleanup instead of being rebuilt by hand.