ダウンロードフォルダの整理: the setup order that holds up

Most instructions for cleaning up the Downloads folder open with "create folders for each file type." That is the fourth decision, not the first, and starting there is why so many of these setups survive two weeks. The parts that determine whether a setup lasts are decided before any folder exists: what signal identifies a file as finished with, what must never be touched, and how a bad run gets reversed. Build those in the wrong order and the first accident takes the whole arrangement with it, because there is no way to tell what went wrong or how to put it back. What follows is an order that holds, with the command to run at each step.

Step one: count before designing anything

The first step is measurement, not classification. Three numbers decide almost everything that comes after.

ls -1 ~/Downloads | wc -l
du -sh ~/Downloads

Under a hundred items, building automation costs more time than it saves; a single afternoon of manual sorting wins. Past several hundred, reading the list at all has stopped being possible, and rules become the only option. The next number is the composition:

ls -1 ~/Downloads | sed -n 's/.*\.//p' | tr 'A-Z' 'a-z' | sort | uniq -c | sort -rn | head

The top three extensions in that output are the only ones worth writing conditions for. Everything below them is a long tail that will not move the item count no matter how carefully it is categorized. Size is a separate question from count, and confusing the two leads to sorting a thousand small documents while a handful of disk images hold the actual space:

find ~/Downloads -type f -size +200M | head

If that command returns a short list and the disk is the complaint, the whole project is a ten minute job with no automation involved.

Recording these three numbers somewhere is worth the thirty seconds. They are the only baseline available for deciding later whether the setup is working. Without them, the question "has this helped" has no answer except an impression, and impressions about a folder that is never empty tend toward the negative regardless of what the rules did. Re-running the same three commands a month later gives a direct comparison, and the count is usually the number that moved most.

Step two: write the exception list before writing any rule

The next step is listing what must never be moved. Doing this after the rules are written means discovering the exceptions by watching them break.

Four categories cover most of it. Files still downloading, which browsers write under a temporary name and rename on completion, so acting on them mid write produces a corrupt result. Disk images that are still mounted, which fail to move or detach unexpectedly. Aliases and symbolic links, whose targets break when the original moves. And files another application remembers the path to: video project media, build dependencies, an export destination configured months ago.

None of these are visible as exceptions when looking at the folder. A mounted disk image and an unmounted one look the same in a listing. A symbolic link and the file it points at look the same. That is precisely why the list is written first, from knowledge of how the machine is used rather than from inspection of what is on screen. Writing it takes about five minutes and it is the only step here that cannot be recovered by rerunning something.

This step also exposes a structural problem worth catching early. If the Downloads folder is being used as a working directory, meaning files get downloaded and then edited in place, the exception list grows until no useful rule can be written. The fix is not a cleverer condition. It is moving active work out of the folder so that Downloads goes back to being a place things arrive rather than a place things live. A related move is pointing the browser at a separate folder and leaving Downloads for everything else, which splits deliberately fetched files from received ones and allows a stronger rule on one side than on the other.

Step three: fix the trigger attribute before choosing destinations

A rule needs a signal for which files qualify. The common choice is modification date, and on this folder it is the wrong one. A downloaded file usually carries the modification date from the server, so a specification published three years ago sorts as three years old the moment it lands.

The correct attribute is the date the file appeared in the folder, which macOS records separately:

mdls -name kMDItemDateAdded ~/Downloads/example.pdf

Written as a query against the index, everything older than thirty days looks like this. The number is in seconds:

mdfind -onlyin ~/Downloads 'kMDItemDateAdded < $time.now(-2592000)'

A setup built on modification date behaves in a way that looks random from the outside. It carries off reference material downloaded yesterday, and it leaves files that have been ignored for months because they were opened and saved once. Nearly every complaint that automatic sorting "grabs the wrong things" traces back to this single substitution. Fixing the attribute before choosing destinations means the destinations only ever have to be decided once.

Step four: one destination, dated

Two destinations are enough to start: an archive folder named by month, and a holding area for anything the rule matched but should not act on.

Dating the archive rather than subdividing it by type is deliberate. A folder named 2026-09 can be found from a vague memory of when something arrived, and requires no decision at write time. Subdividing by type adds a decision on the way in and a guess on the way out, and search already answers type based questions without any folder structure at all.

There is a second reason to keep the archive flat. Every subdivision is a branch that the rule has to choose between, and branches are where rules acquire bugs. A rule with one destination either moved a file or did not, and the printed log answers the question completely. A rule with eight destinations can be wrong in eight ways, most of which look identical from the outside: the file is gone from Downloads and is not where it was expected. Debugging that means checking eight folders. Adding destinations later, once the single flat archive is demonstrably working, costs nothing; starting with them costs every subsequent investigation.

The holding area earns its place as a diagnostic. Whatever accumulates there is the list of cases the condition is too coarse for. If it stays empty, the condition is correct and can be trusted with more. If it fills up, the condition needs narrowing before the rule is allowed to run unattended.

Step five: run it as a list, then as an echo

This is the step that gets skipped, and skipping it is where the accidents come from. Before any file moves, count what the condition matches:

mdfind -onlyin ~/Downloads 'kMDItemDateAdded < $time.now(-2592000)' | wc -l

A surprising number means the condition is wrong. Zero means the query has a syntax problem rather than no matches. When the count looks right, run the real command with the action printed instead of performed:

mkdir -p ~/Archive/2026-09
mdfind -onlyin ~/Downloads 'kMDItemDateAdded < $time.now(-2592000)' | while IFS= read -r f; do
  echo mv "$f" ~/Archive/2026-09/
done

Removing echo turns it into the real thing. Reading that printed list is what surfaces the exceptions from step two that were forgotten, and reading it costs a few seconds against a cleanup that can take an hour. Conditions get corrected here, not after execution.

Step six: keep moving and deleting in separate stages

Moving and deleting should never run from the same rule. One is reversible by looking in the destination. The other is not, once the Trash is emptied.

The arrangement that works is two stages separated by time. Stage one moves anything past a chosen age into the dated archive. Stage two considers items that have been sitting in the archive for a further period, and it does not need to be automatic at all: opening that folder once a month and looking is sufficient. The fact that nothing was missed during the archive period is the evidence that deletion is safe, and no other evidence is available at the moment of the move.

Where deletion is automated, send items to the Trash rather than removing them. macOS can empty the Trash automatically after 30 days, which leaves a real window in which a mistake can be caught. Having that window is what makes it reasonable to write a stricter condition, since the cost of being slightly wrong drops to reopening a folder.

Duplicates belong in the deletion stage, not the moving one. Downloading the same file twice produces a numbered copy rather than an overwrite, and the numbered copy is not necessarily the newer content. Comparing by content is possible but gets slow as the count rises, so during the first months it is simpler to archive duplicates along with everything else and compare them inside the archive when there is time.

Step seven: decide when it runs

The last decision is execution, and there are three options with clearly different failure modes.

How it runs	Requires	Suits	Misses
Manually	Remembering to run it	The period while conditions are still changing	Whatever accumulates between runs
On a schedule	The Mac awake at that time	Daily or weekly maintenance	Every run where the lid was closed
On folder change	A watcher running at login	Sorting things the moment they arrive	Files still being written

For schedules, a launchd agent in the user Library is the built in mechanism. On a laptop that travels, a daytime hour misses far fewer runs than an overnight one. For change driven rules, Folder Actions are built in, but the Downloads folder is written to constantly, so acting on the change itself catches partial downloads. Restricting the action to files that have existed for some minutes avoids that, and at that point the behavior is close enough to a schedule that the extra machinery earns little.

Keep it manual while conditions are still being adjusted, and automate only after the dry run has produced the expected list three times running. Once it is automatic, log each run to a text file. The log does not prevent accidents; it determines whether a missing file can be traced to the rule or not, and an untraceable disappearance is what makes people switch the whole thing off.

What to change first

If none of the seven are decided yet, start with the trigger: fix on date added and confirm the query returns a sane count. If that is already settled, create one dated archive folder and move a month's worth into it before writing anything automated.

The loop underneath all seven steps is the same, and it repeats until the conditions settle: look at the folder, adjust the query, dry run it, look at the folder again. When each of those happens in a different window, the cost is not the thinking but the re-navigating, and it is paid again on every single adjustment. A file manager that keeps the listing and the command line pointed at the same directory removes that cost without changing any of the seven decisions. What Atriens covers in one window is listed on the Features page, common setup questions are answered on the FAQ page, and continuing a run from a phone is described on the From iPhone and iPad page.