フォルダの自動振り分け: what it does and where it breaks down

The phrase フォルダの自動振り分け, automatic folder sorting, covers at least four mechanisms on a Mac, and they do not do the same thing. Two of them change how files are displayed and leave the disk untouched. Two of them actually move files. Setting up the first kind while expecting the second is the most common reason a Downloads folder still has four figures worth of files in it a month after somebody decided to fix the problem.

What follows separates the four, states what each one can read when it makes a decision, and marks the point where each stops being reliable. None of this requires buying anything to test.

Two of these change the view, two change the disk

The split that matters is whether a file's path changes.

Mechanism	Path on disk	Cost of undoing it
Desktop stacks	Unchanged	Turn the setting off
Saved searches (smart folders)	Unchanged	Delete the saved search
Event triggered scripts	Changed	Move the files back by hand
Scheduled runs	Changed	Move the files back by hand

The top two make a cluttered folder look organized. The bottom two make it be organized. Both produce a tidier screen within a minute of being switched on, which is why articles about this subject tend to blur them together.

The difference surfaces later, in three places. Disk space: stacks free none of it. Backup scope: a saved search cannot be excluded from a backup, because it is not a location. Handing a folder to somebody else: the recipient sees the raw directory, not the arrangement. If any of those three matter, the view based options are not the answer, no matter how good the desktop looks afterwards.

What the view based options actually do

Desktop stacks arrived in macOS Mojave 10.14. Clicking the desktop and choosing View then Use Stacks, or pressing Control-Command-0, collapses the icons into piles. The grouping axis is set under View then Group Stacks By.

You can group stacks by kind (such as images or PDFs), date (such as the date a file was last opened or created), or Finder tags. Source: support.apple.com

Nothing moves. Listing the same directory in a terminal returns exactly what it returned before the piles appeared.

Saved searches behave the same way at a different scale. A smart folder gathers everything matching a set of conditions into one window, and the search itself is stored as a small file under ~/Library/Saved Searches/ with a .savedSearch extension. That file holds the query, not the results. Deleting it removes the view and nothing else.

Both of these solve exactly one problem, which is finding a known file quickly. That is a real problem and worth solving. It is just not the same problem as a folder that has grown past the point where anything can be found by scrolling.

There is a related option that sits between the two categories and gets overlooked: Finder tags. A tag is stored on the file itself rather than in a view, so it travels with the file when it is moved and survives being copied to another folder. That makes tags useful as an input to the moving mechanisms later on, since a rule can act on a tag. The catch is that applying tags is a manual step, which puts the effort back on the person the automation was supposed to help. Tags work well as a small vocabulary applied deliberately to a few dozen important files, and poorly as a general filing system.

The practical reading is that the view based options are worth turning on immediately because they cost nothing and can be reversed in one action. They are just not a substitute for deciding where things live.

What the mechanisms that move files are triggered by

macOS ships with three separate ways to run something when files appear, and they differ mainly in what wakes them up.

Folder Actions attach a script to a specific folder and run it when an item is added. The configuration app lives at /System/Library/CoreServices/Applications/Folder Actions Setup.app, and thirteen sample scripts are installed at /Library/Scripts/Folder Action Scripts/. The samples handle image rotation, format conversion, and an alert when new items arrive. Attaching one of the samples to a test folder is the fastest way to confirm the whole chain is working before writing anything custom.

Launch agents watch from the background. A property list can name paths to watch for modification, name directories to stay alive while they are not empty, or simply fire every so many seconds. This is the most flexible option and the least forgiving, because the rules about what counts as a change are not obvious.

Shortcuts sits between the two. The app is at /System/Applications/Shortcuts.app, and a shortcuts command line tool is installed alongside it with run, list, view and sign subcommands. That combination is useful: the logic gets built in a visual editor, and something else decides when to run it.

These three compose. A common arrangement puts the decision logic in a shortcut and the trigger in a launch agent, so that the part that changes often is editable without touching the part that rarely changes.

What a rule can actually read

Every tool in this category, paid or free, decides based on the same underlying pool of attributes. The syntax differs. The available facts do not.

Attribute	Effort to use	Where it fails
Extension	Trivial	Same content, different spellings
Substring in the name	Trivial	Requires naming to already be consistent
Created, modified, added dates	Trivial	The three often disagree
Finder tags	Trivial	Tagging stays a manual step
Where the file came from	Moderate	Absent on most files
Text inside the file	Heavy	Useless on images and scans

The fifth row is the one that gets oversold. Browsers write the originating URL into an extended attribute when a file is downloaded, and rules of the form "anything from this site goes in that folder" read it. The attribute is real and it works. The problem is coverage.

Counting a genuinely overgrown Downloads folder on one Mac, 383 of 1,062 files carried that attribute. That is 36 percent. The other 64 percent were screenshots, AirDrop transfers, copies from external disks, and files an application wrote directly. A rule set built around provenance simply has no opinion about two thirds of what is sitting there.

Extensions have a quieter version of the same problem. On the same machine, images were spread across jpeg with 57 files, jpg with 42, and heic with 37. A single rule for photos would have caught somewhere near a third of them and left the rest in place, which reads as "the rule is broken" rather than "the rule was too narrow".

Dates carry a third version of it. A file has a creation date, a modification date, and a date added to the current folder, and on a downloaded file all three can differ. The creation date often reflects when the original was made on somebody else's machine, months before it arrived. A rule sorting by year using the wrong one of the three will file this year's downloads under three different years and appear to be behaving randomly. Naming which date a rule reads, rather than accepting whatever the tool offers first, removes a whole category of confusing results.

None of these limits argue against sorting automatically. They argue for looking at the folder before deciding which attribute to build the rules on, because the attribute that sounds most useful in a feature list is frequently the one with the worst coverage in practice.

Where each mechanism stops being reliable

Building the rules is not the hard part. Every one of these tools can be configured in an afternoon. The failures arrive in week two, and they cluster.

Name collisions come first. When a file arrives with a name that already exists at the destination, the default behavior differs between tools: overwrite, append a counter, or stop. A configuration that silently overwrites is not recoverable, and it is sometimes the default.

Partial downloads come second. A file still being written sits under a temporary name, and the suffix depends on the browser. Safari uses .download, Chrome uses .crdownload, Firefox uses .part. Event triggered rules fire on arrival, which can mean firing on a file that is still growing.

Permissions come third. Anything reaching into Downloads, Desktop or Documents needs access granted in System Settings, and the grant is per application. A script run by a launch agent inherits the permissions of whatever is executing it, not of the script, which makes the failure look like a logic error when it is an access error.

Missed events come fourth, and this one is documented rather than accidental. The manual page for launch agent property lists, readable by typing man launchd.plist, states that using the path watching key is strongly discouraged: filesystem event monitoring is race prone, modifications can be missed entirely, and when one is caught there is no guarantee the file is in a consistent state at the moment the job starts. That is the system's own description of the mechanism, not an outside opinion.

Sleep comes fifth. Interval based runs scheduled while the machine is asleep do not queue up quietly and execute later by default. Deciding in advance whether a missed run should be caught up or skipped avoids a category of confusion when a Monday morning produces nothing.

Three questions that locate the actual problem

The mechanisms above map onto different complaints, so it helps to name the complaint precisely.

Is the problem finding things, or is the problem that nothing has a home? If files can be located when needed and the folder is merely ugly, the view based options are sufficient and free. If the same file exists in three places and none of them is authoritative, only the moving options help.

Does the information a rule would need already exist on the files? If provenance is absent and names are inconsistent, writing rules first is backwards. Changing how files get named at the moment of creation produces more improvement per hour than any rule engine, and it makes the rules that come later much shorter.

After sorting, will those folders be opened, or will the files be reached by search anyway? Search is very good on a Mac. Sorting files into a hierarchy nobody navigates is work that produces a feeling rather than a result.

The comparison page sets out how tools in this space divide up along these lines, and the FAQ covers the questions that tend to arrive in the first week of running rules against a live folder.

What to change first

Count two things before writing a single rule: the extension spread in the folder, and the share of files that carry provenance. Those two numbers decide whether three rules will cover most of the problem or thirty will cover half of it. 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.