ダウンロードフォルダの整理: what it does and where it breaks down

The Downloads folder is an inbox with no outbox. Files arrive from browsers, mail attachments, AirDrop, and chat clients, and nothing ever removes them. After a year the folder holds installers for apps already installed, three copies of the same invoice, a disk image still mounted from last spring, and a few hundred files whose names say nothing about what is inside. Searching for how to fix this returns two answers that sound similar and are not: sort everything into folders by file type, or delete the lot. One changes where files live. The other changes how many there are. Deciding which problem is actually in the way is the whole job, and it takes about a minute once the four possible jobs are separated.

The phrase covers four different jobs

"Organizing the Downloads folder" is used for four operations that change different things and carry different risk.

Job	What changes	Reversible	Fixes
Make things findable	Nothing on disk. Only the way files are surfaced	Nothing to undo	You cannot locate a specific file
Move	Location, and how many items the folder shows	Yes, if the destination is known	The folder is slow or unreadable
Delete	Free space and item count	Only while the Trash holds it	The disk is full
Rename	The text in the listing	Only if the old names were recorded	Names say nothing about contents

Most guides collapse these into one workflow, which is where the trouble starts. A rule that moves files can be undone by looking at the destination. A rule that deletes them cannot. Running both from the same trigger means that when something goes wrong, there is no way to tell which half caused it, and no way to reverse the half that did.

Picking the right job first removes work. "Which PDF did the accountant send last week" is a findability problem, solvable without touching a single file. "The folder takes eight seconds to open" is a count problem, and only moving or deleting will change it. "The startup disk is full" is a space problem, and only deleting or offloading will change it. Applying a file type taxonomy to any of these three is optional, and for the first one it is entirely beside the point.

Searching changes nothing on disk

The lowest risk direction is to add ways of finding things rather than ways of storing them. macOS indexes file metadata continuously, and a saved search presents everything matching a condition as though it were a folder. The condition is what gets saved, not the files, so deleting a saved search leaves every file where it was.

Two metadata attributes do most of the work here. The first is the date a file appeared in its current folder, which macOS records separately from the modification date. This matters because a downloaded file usually carries the modification date the server had, so a document written three years ago and downloaded this morning sorts into the middle of the list. The second is the address the file came from, recorded for anything that arrived over the network. A file named download-2.pdf is opaque; the source URL attached to it usually is not.

Both are readable from a shell without opening anything:

mdls -name kMDItemDateAdded -name kMDItemWhereFroms ~/Downloads/download-2.pdf
mdfind -onlyin ~/Downloads 'kMDItemDateAdded > $time.today(-7)'

Tags sit in the same category. A file can carry several of them, which folders cannot offer, and applying one moves nothing. The limitation is that tags have to be applied by someone. In a folder filled by other people's attachments and by installers downloaded once and forgotten, nothing arrives pre-tagged, so the backlog stays untagged unless a rule applies tags automatically.

What this direction cannot do is reduce anything. The item count stays identical. Duplicates stay. The folder opens exactly as slowly as before. Search shortens the time spent looking for a known file; it does nothing for the time spent staring at a list deciding what is safe to remove.

What a sorting rule is actually made of

Every automatic sorting setup, whether written as a shell script or built in a graphical rule editor, has three parts: a trigger that decides when to evaluate, a condition that decides which files match, and an action that decides what happens to them. Setups fail when one of the three was never decided explicitly.

Triggers come in two shapes. Event driven rules fire when the folder changes, which on macOS is what Folder Actions provide. Schedule driven rules fire at a fixed time, which is what a launchd agent provides. The difference is not cosmetic. An event driven rule fires the instant a browser creates the file, which is before the browser has finished writing it. Browsers write to a temporary name while downloading and rename on completion, so a rule that acts immediately can move a half written file. Adding "only files older than a few minutes" to the condition fixes it, and at that point the rule is close to a scheduled one anyway.

Conditions have more to work with than most setups use. File extension is the obvious one. Date added, source URL, size, and name pattern are all available, and all of them carry more meaning than the extension does. Screenshots, for instance, are easier to catch by their name pattern than by being PNG files, because most PNG files on a Mac are not screenshots.

Actions should start as moves. A move to a dated folder is a single reversible step. Deletion, compression, and renaming can all be added later, once the condition has been observed producing the expected list several times in a row.

Where extension based rules stop working

Sorting by extension is the example in nearly every tutorial because it is easy to write. It also degrades faster than any other approach, for a structural reason: an extension describes a format, and formats do not map onto purposes.

A PDF folder collects invoices, appliance manuals, event tickets, contracts, and academic papers. A PNG folder collects screenshots, diagrams pulled for a deck, and photos someone sent. A ZIP is unknowable until it is opened. After a few months the PDF folder is the Downloads folder again, with the same count and the same opacity, one level deeper. The files moved; the problem did not.

There is a second effect that shows up later. Sorting by format scatters the pieces of a single piece of work. The proposal PDF, the source PNG assets, and the CSV behind the chart land in three different places, and the project can no longer be retrieved as a unit. If the unit of work is a project rather than a format, a format based structure was mismatched from the start.

Conditions closer to purpose hold up better. Source URL separates documents from an accounting portal from documents from a hardware vendor, even though both are PDFs. Name pattern separates screenshots from everything else. Date added separates what is still live from what is not, without anyone deciding what any individual file means. All three take longer to write than an extension match. All three still work a year later.

What macOS will not do on its own

There is no expiry on the Downloads folder. System Settings offers an option to empty the Trash automatically after 30 days, and that option applies only after something has been placed in the Trash. Nothing ships that moves, archives, or removes items in Downloads on a schedule. Left alone, it becomes the largest and slowest folder in the home directory, and it does so quietly.

The tools to build the missing behavior are all present. Automator and the Shortcuts app build the actions. Folder Actions attach an action to a folder. launchd runs anything on a schedule. A few lines of shell do the same with less setup. None of these is a rule engine with a list of conditions and a history of what it did, which is the gap that paid utilities fill. Whether that gap is worth filling depends on how many rules are actually needed, and that number is usually smaller than it feels at the planning stage. Comparisons of the available approaches are collected on the Compared with other file managers page.

One more default deserves attention. Anything downloaded over the network carries a quarantine attribute, which is what produces the warning on first open. The attribute travels with the file, so moving a downloaded item into another folder does not clear it. Scripts, fonts, and libraries pulled through a browser arrive with it attached and can fail to load later with errors that do not mention the cause.

Permissions, background processes, and sleep

The part that rarely appears in tutorials is what it takes to keep a setup running.

Anything that watches a folder has to be running to watch it. That means a login item, and it means changes that happen while the Mac is asleep are not observed. Anything that runs on a schedule does not need to stay resident, but it does need the Mac to be awake at that time. On a laptop that gets closed and carried, a 3 a.m. schedule simply does not run, and the folder quietly stops being maintained without any error appearing.

There is a related failure that looks like a bug and is not. A rule that has been idle for a week fires on the next run and processes seven days of accumulated files at once. Nothing is wrong, but the result on screen is a folder that empties in a single sweep, which is alarming enough that people disable the rule before checking the destination. Logging what each run moved, to a plain text file, turns that moment into something answerable in a few seconds instead of a reason to abandon the setup.

Permissions are the other half. Rules that read or write outside the home folder, or that touch locations another app manages, need explicit approval in the privacy settings. Without it, some operations fail silently rather than reporting an error, which is the most common reason a setup described as "configured correctly" does nothing at all. Keeping both the source and the destination inside the home folder avoids most of this, which is another argument for a plain dated archive folder over an elaborate destination tree on an external volume.

What to change first

Decide which of the four jobs is the one in the way, because the answer determines everything after it. If files cannot be found, save a search and move nothing. If the folder is unreadable, move everything older than a set number of days into one dated folder and delete nothing yet. If the disk is full, look at the largest items before looking at any of them.

If the loop of listing files, writing a condition, running it, and checking the result is currently spread across a file browser window, a terminal window, and a chat window, that split is costing more than the decisions are. Reading what Atriens keeps in a single window, or checking the Pricing page, takes less time than rebuilding a taxonomy that will drift again in three months.