ダウンロードフォルダの整理 not working: what to check, in order

The rule exists. It is switched on in the settings window. The folder it watches is the right one. And the same seventeen files are still sitting in Downloads, exactly where they were yesterday. This is the state most people are in when they start searching for ダウンロードフォルダの整理 fuguai, and the temptation at that moment is to open the rule and start changing conditions. That is the wrong first move. Changing the condition of a rule that never ran produces a more complicated rule that still never runs, and now nobody knows which parts were ever necessary.

Automated filing on macOS fails in a small number of places. The places are predictable enough that a fixed order of checks will find the cause in a few minutes, and the order matters more than the individual checks, because each stage rules out everything above it.

Start with a probe file, not with the rule

Before anything else, create one file that cannot fail to match. If the rule moves PDFs older than a day into an archive folder, make a PDF and set its dates so it qualifies. If the rule matches on a name pattern, name a plain text file to match it exactly. Drop that file into the watched folder and wait for one cycle.

This single step splits the problem in half. If the probe moves and the real files do not, the machinery is fine and the cause is in matching: the condition does not describe the files that actually arrive. If the probe does not move either, matching is irrelevant for now and the cause is upstream, in whether the rule runs at all and whether it is allowed to touch the folder.

Most wasted debugging time comes from skipping this. Someone spends an hour refining a date condition on a rule whose background process has not been running since the last restart, and the refinement is invisible either way.

Stage one: is anything running

Event driven filing depends on a process that stays alive. That process can be an app that watches folders, a folder action attached by Automator, or a launch agent that runs on a schedule. All three can be present in configuration and absent in memory.

Login items are the usual culprit after an OS update, which can quietly reset which background items are permitted. Check System Settings, General, Login Items and Extensions, and look at both lists: the apps that open at login and the background items allowed to run. A rule engine that appears in the second list but is switched off will show a perfectly healthy settings window and do nothing.

For anything installed as a launch agent, the loaded state is visible directly:

launchctl list | grep -i <part of the label>

An empty result means the job is not loaded, and no amount of editing its configuration will change today's behavior. A result that shows a non zero exit status in the first column means the job ran and failed, which is a different problem and belongs to stage five.

Folder actions have their own switch that is easy to lose. Control click the folder in Finder, open Folder Actions Setup, and confirm that the folder is listed, that the checkbox next to it is ticked, and that the intended script is attached to that specific folder. Attaching a script and enabling folder actions globally are two separate steps, and the second one is frequently the one that is missing.

Stage two: is it watching the folder that receives files

A rule pointed at the wrong directory behaves exactly like a rule that never runs. Three variants of this show up repeatedly.

The first is a path that resolves differently in a background context. A tilde expands to the home directory of whoever runs the process. Inside a launch agent that runs as a different user, or inside a configuration file that stores the string literally, the tilde may expand somewhere else or not at all. Absolute paths in configuration remove the ambiguity.

The second is a symbolic link or an alias standing in for the real folder. Some tools follow links and some stop at them. One line settles it:

ls -ld ~/Downloads

A leading l and an arrow pointing somewhere else means the folder being watched is not the folder the browser writes into.

The third is a volume that is not mounted when the rule fires. Rules that archive into an external drive fail silently while the drive is unplugged, and because the failure is per run rather than permanent, it looks like intermittent flakiness rather than a configuration error.

Stage three: permission, not configuration

macOS gates access to several user directories per application. The gate is granted to the process that performs the work, which is not always the process that appears to own the rule.

The signature symptom is precise: running the same script by hand in Terminal succeeds, and running it from the scheduler does nothing. Terminal has been granted access at some point in the past. The launch agent, the automation app, or the helper it spawns has not. Open System Settings, Privacy and Security, Full Disk Access, and confirm that the thing doing the work is listed and enabled. Adding an entry there usually requires the process to be restarted before the new grant applies.

Sandboxed applications have a second constraint that is easy to mistake for a bug. A sandboxed app may only write where the user has explicitly pointed it, so the act of selecting a folder in its settings is also the act of granting access to that folder. Deleting and recreating a destination folder invalidates the grant, and the rule that worked last week stops working with no visible change to its configuration. Reselecting the folder restores it.

Stage four: the condition does not describe the files

Once the probe file proves the machinery works, attention moves to matching. Four causes cover most of it.

Date Modified is not arrival time. A downloaded file usually carries the modification date the server reported, which can be years old. A rule that archives files older than thirty days will sweep up a reference document downloaded this morning, and a rule that processes files newer than one day will skip it. The attribute that records arrival is Date Added, exposed to the shell as kMDItemDateAdded and available in Finder through View, Show View Options.

Extension case. Conditions written against .jpg and files arriving as .JPG are a classic silent miss, particularly with files coming from cameras and from Windows machines.

Type is decided by uniform type identifier, not by the extension string. A file with no extension, or with an extension that contradicts its contents, lands in a category nobody predicted.

The file was still downloading. Browsers write to a temporary name, .crdownload in Chromium browsers and .download in Safari, then rename on completion. A rule that fires the instant something appears inspects a partial file with the wrong name, decides it does not match, and never looks again, because the rename may not register as a fresh arrival.

Verifying a condition against a real file takes one command:

mdls -name kMDItemDateAdded -name kMDItemWhereFroms -name kMDItemContentType ~/Downloads/example.pdf

Comparing those values against what the rule asks for is the whole of stage four. The fix for partial files is either a condition requiring a minimum age, five minutes is generous and sufficient, or a move away from arrival triggers toward a scheduled run.

Stage five: matched, but the move failed

A rule can select a file correctly and still leave it in place. The reasons are mechanical.

Symptom	Likely cause	Check
Nothing happens, no error	Name collision, conflict policy set to skip	Open the destination and look for the same name
Fails only for some files	File open or locked	ls -lO shows uchg on locked files
Fails consistently since a change	Destination missing or not writable	Confirm the destination path exists
Fails for large files only	Cross volume move needs free space	Check available space on the target
Works, then the file is gone	Policy set to replace or delete	Check Trash and the destination timestamps

Name collisions deserve special attention because they fail quietly. Monthly statements arriving with identical names hit this every cycle, and the observable result is that the rule appears to work for eleven months and then stops.

Quarantine is worth naming here only to dismiss it. The com.apple.quarantine attribute affects opening a file, not moving it. Stripping quarantine attributes to fix a filing problem changes nothing about the filing and removes a useful signal about where files came from.

Stage six: the schedule fired into a sleeping Mac

Scheduled filing that works on a desktop and behaves erratically on a laptop is usually not a rule problem. A job scheduled for three in the morning on a machine that is closed at night either runs late when the lid opens or skips the interval entirely, depending on how it was registered.

The cheapest diagnostic is to make the job announce itself. One line appended to a log file at the top of the run, before any condition is evaluated, separates two questions permanently: whether the job ran, and whether it did anything. Without that line, both failures look identical from the outside, and every future investigation starts from zero.

Making the next failure cheaper

Rules drift. A browser changes its default download location, macOS updates and resets a background item, a destination folder gets renamed during a cleanup. Three habits keep the next investigation short.

Test conditions against a scratch folder before pointing them at Downloads, so a wrong condition moves test files rather than a quarter's worth of invoices. Log every action the rule takes, with source and destination, because a filing system without a record is a filing system nobody can audit. Note the date whenever a rule changes, which turns "it used to work" into a specific window to examine.

There is one more cost that this kind of debugging carries, and it is structural rather than technical. Every stage above alternates between looking at a folder, running a command against a file in it, reading the output, and looking at the folder again to see whether anything changed. On a Mac with Finder in one window, a terminal in another, and an assistant in a third, a five minute diagnosis becomes twenty minutes of window switching, most of it spent reopening the same directory in each place.

What to change first

Stop editing conditions and drop a probe file in the folder. That one action tells whether the problem is the machinery or the matching, and every remaining check follows from the answer. If the diagnosis itself is the slow part, because the folder, the shell, and the assistant each live in a separate window, that is worth fixing too: see what belongs in a single window in Features, how that differs from Finder plus a separate terminal in Compared with other file managers, and the practical questions people ask before switching in the Atriens FAQ.