フォルダの自動振り分け: the setup order that holds up

Almost every guide to フォルダの自動振り分け starts at the same place, which is opening a rule editor and writing a rule. That order is backwards, and it is why so many of these setups are abandoned two weeks later with half the folder sorted and the other half untouched. The rules are rarely wrong. They were written against assumptions about the folder that turned out to be false, and by the time that becomes visible the trigger is already running and files have already moved.

The order below inverts that. Measurement first, destinations second, rules third, and the trigger last. Nothing here depends on a particular application, so it applies equally to the tools included with macOS and to a purchased rule engine.

Measure the folder before writing anything

Two numbers determine how many rules are needed, and both take minutes to obtain.

The first is how the file types are distributed. Counting one Mac's Downloads folder produced 197 PNG files, 165 PDFs, 137 CSVs, 84 MP4s, 66 DOCX files, 57 JPEG, 50 TXT, 42 JPG, 37 XLSX and 37 HEIC. Two things follow from a distribution shaped like that. Roughly five rules would cover most of the volume, so a large rule set is not required. And images are split across three extensions, so any rule written for photos has to name all three or it will appear broken while actually being too narrow.

The second is how many files carry the attribute recording where they came from. Browsers write the originating URL into extended metadata during a download, and rules of the form "anything from this domain goes to that folder" depend on it. On the same folder, 383 of 1,062 files had it. That is 36 percent. Screenshots, AirDrop transfers, copies from external disks and files written directly by applications have none, so a rule set organized around provenance would be silent about roughly two thirds of the folder.

Doing this measurement before writing rules changes what gets written. Doing it afterwards produces a rule set that looks reasonable and covers a third of the problem.

Name the destinations before naming the conditions

The second step is deciding where files are going, and it is worth doing on paper before touching any configuration.

The failure mode here is building a taxonomy instead of a set of destinations. A taxonomy is a tree that is correct and that nobody navigates: Documents, then Work, then Clients, then the client name, then the year, then the quarter. Every level is defensible and the result is six clicks from the top. Files land in it correctly and are then found by search anyway, which means the sorting produced tidiness and no time savings.

A destination is different. It is a folder somebody actually opens during a normal week. Three to six of them is usually the whole list. Anything that does not belong in one of those goes to a single holding folder, and the holding folder is reviewed occasionally rather than being eliminated.

Write the list down and check each entry against one question: in the last month, was this folder opened deliberately? If the answer is no, it is a category, not a destination, and it should be merged into something else. Rules pointing at folders nobody opens are pure overhead: they cost maintenance and return nothing.

Write the first rule as a simulation, not a move

The third step is the first rule, and it should not move anything on the first run.

Every serious tool in this category has a way to preview. The open source tool organize has an explicit simulation mode, organize sim, which evaluates the entire rule set and prints what each rule would have done without touching a file. Rule engines with a graphical editor offer a preview of matching files. A hand written script can be made to print its intended actions instead of performing them by putting an echo in front of the command that moves the file.

Run the preview against the real folder, not a test folder with six files in it. Test folders contain files that were chosen to match, which is why they pass. Real folders contain files with parentheses in the name, files with no extension, files whose extension does not match their contents, and files that are currently open in an application.

Read the preview for two specific things. First, the count of files the rule matched. If a photo rule matched 42 files in a folder known to contain 136 images, the extension list is incomplete. Second, whether any destination path appears twice for two different source files with the same basename. That is a collision, and it is the subject of the next step.

Decide the collision behavior explicitly

When a file arrives at a destination where that name already exists, three outcomes are possible: overwrite, rename with a counter, or stop and report. Every tool picks one by default and they do not all pick the same one.

This is the only step in the entire process where getting it wrong is unrecoverable. A move that overwrites leaves no trace of what was there, and a rule running on a schedule can do it repeatedly without anyone noticing for weeks. The other failure modes in this article cost time. This one costs files.

Set it to rename or to stop, verify the setting rather than assuming it, and only consider overwrite for a folder that is explicitly a mirror of something else. Duplicate handling and collision handling are not the same feature, and a tool that offers duplicate detection does not necessarily default to safe collision behavior.

Collisions are more frequent than they sound, because the names that collide are generated rather than chosen. Camera exports, bank statements, invoices from the same supplier and screenshots all produce names from a small template, so the same basename arrives repeatedly across months. A rule that files statements by type and not by date will generate a collision every billing cycle. Adding the date into the destination filename, rather than only into the destination folder, removes most of this class before it starts.

One more habit is worth adopting at this step: keep the first few weeks of moves reversible by sorting into folders rather than into an archive that gets compressed or uploaded. Undoing a move is trivial while everything is still a plain folder on the same disk. It stops being trivial the moment a rule also archives, uploads or renames as part of the same action.

Choose the trigger last, and choose it deliberately

Only at this point is it worth deciding what makes the rules run. Choosing the trigger first is the most common ordering mistake, because it locks in constraints before the rules are understood.

Trigger	Fires on	Main limitation
Folder Action	An item added to a watched folder	Fires on partial files too
Launch agent watching a path	The path being modified	Events can be missed
Launch agent on an interval	Every N seconds	Runs during sleep are skipped
Manual command	Being typed	Requires remembering

The second row deserves attention, because the limitation is documented rather than folkloric. The manual page for launch agent property lists, readable by typing man launchd.plist, says that use of the path watching key is highly discouraged, that filesystem event monitoring is race prone and modifications can be missed entirely, and that when a modification is caught there is no guarantee the file is in a consistent state at the moment the job starts. That is the operating system describing its own mechanism.

For a Downloads folder, the interval option is usually the better trade. Sorting fifteen minutes after a file arrives is fine, whereas sorting a file that is still being written is not. The manual option is genuinely underrated for anyone who is still adjusting rules, since running the command by hand keeps a person looking at the output during the period when the rules are most likely to be wrong.

What breaks once real files start arriving

Five things go wrong in the first fortnight, and all five are predictable.

Files still downloading get moved. A download in progress sits under a temporary name whose suffix depends on the browser: .download for Safari, .crdownload for Chrome, .part for Firefox. An event triggered rule can fire on one of those, or on the finished file a fraction of a second before the rename completes. Excluding those three suffixes explicitly, and adding a short delay before acting, removes the problem.

Permissions fail in a way that looks like broken logic. Anything reaching into Downloads, Desktop or Documents needs access granted in System Settings, and the grant attaches to the application doing the execution rather than to the script. A rule that works when run by hand and silently does nothing when run by a background agent is almost always this.

Scheduled runs vanish during sleep. An interval based job whose time arrives while the machine is asleep does not queue up quietly by default. Deciding in advance whether a missed run should be caught up on wake or simply skipped prevents a Monday morning with no output from turning into an hour of debugging.

Rules stop matching after a macOS update. Permission handling changes between major releases, which is worth knowing before concluding the rule itself is at fault.

The rule set becomes unreadable. Twelve rules written across three weeks is a small program, and rereading it six months later is the real maintenance cost. Keeping the list short is worth more than making each rule clever. A useful discipline is to write one sentence of plain language next to each rule saying what it is for, since the condition itself records what the rule matches but never why it exists.

A sixth item is worth adding for anyone who works across devices. Rules run on the Mac they are installed on, so a file that arrives on a phone or tablet and syncs across is sorted only once it reaches the machine running the rules, and only if that machine is awake. Anyone who regularly starts work on one device and finishes on another should check where each rule actually executes before assuming a folder is being maintained. The mobile continuation page covers how the same folder is reached from a phone or tablet, which is the other half of that question. The comparison page covers how tools in this space differ in how readable a grown rule set stays, and the FAQ covers the questions that surface in the first week of running against a live folder.

The order, condensed

Count the extension spread and the provenance share. List three to six destinations that are actually opened, plus one holding folder. Write one rule and run it in preview against the real folder. Set collision behavior to rename or stop. Then, and only then, attach a trigger, starting with a manual run and moving to a schedule once the output has been correct for several days.

What to change first

Start with the measurement, because it takes minutes and it changes what gets built. If the loop of editing a rule, checking the result in a folder window and confirming it in a terminal is what keeps stalling the work, that specific gap is what Atriens was built to close.