ファイル名の一括変更 not working: what to check, in order

A bulk rename has just gone wrong and the folder is sitting there in some half-finished state. The temptation is to run it again with a slightly different setting. That is usually the worst available move, because a second pass on a set that is already partly renamed produces a mess that cannot be reasoned about afterwards.

The faster path is to spend two minutes classifying what happened. ファイル名の一括変更 fails in four distinct ways, and each one has a different cheapest check. Running the checks in the wrong order is what turns a five minute problem into an afternoon.

Sort the symptom first

Look at the folder and answer one question: how many files have a new name?

None of them means the operation never reached the file system. Either the tool never ran, or it ran and was refused at the boundary. The cause is almost always permission or scope, and nothing about the naming rule matters yet.

Some of them means the operation ran and stopped. Something specific to a subset blocked it partway. The useful work here is identifying exactly which files were left behind, because that set names the cause.

All of them, but wrong means the operation worked perfectly and the rule was not what was intended. This is a rule problem, and it is the only one of the four where running something again is part of the answer.

All of them, correctly, and now something else is broken means the rename was fine and a downstream dependency was not. Nothing in the folder will tell you this. It shows up when an app, a script, or a link fails an hour later.

Write down which of the four this is before touching anything. Each section below handles one of them.

Order the checks by what they cost

The reason to fix an order is that these checks are not equally expensive, and the cheap ones rule out the largest share of causes. Working top to bottom means most sessions end in the first two rows.

Check	What it rules out	Cost
Read the item count in the sheet or status bar	Wrong selection, folder selected instead of contents, search window scope	5 seconds
Read the preview line before pressing Rename	A rule that matches more than intended	5 seconds
Run the same rule on two copies in a new Desktop folder	App permission, sandbox restrictions, locked location	1 minute
Compare a before and after listing	Which subset was skipped, and therefore why	1 minute
Check Privacy and Security entries for the app	Denied Files and Folders, Full Disk Access, Automation consent	3 minutes
Search dependent projects for the old name	Broken references after a successful rename	5 minutes and up

One rule sits above the table. Do not re-run a batch on a set that is already partly renamed. A second pass applies the rule again to files that already carry it, so a prefix gets added twice and a counter restarts in the middle of the sequence. Either undo first, or narrow the selection to only the files that still have their old names.

Nothing changed: check scope before anything else

The single most common reason a batch rename appears to do nothing is that it was aimed at a different set of files than the one on screen.

Selecting inside a search results window pulls in files from every folder the search covered. Selecting a folder and expecting its contents to be included does not work: the folder itself is the item, and only its name changes. Clicking once in a window selects nothing at all, and a selection is dropped the moment the window navigates elsewhere.

The count is the check. Finder's rename sheet states how many items are about to change, and the status bar at the bottom of the window shows how many are selected. If the status bar is not visible, turn it on from the View menu. On the command line the same check is a glob printed before it is used:

ls IMG_*.JPG | wc -l

If that number is not the number in your head, stop. Nothing else in this article matters until the two agree. A rename that ran flawlessly on the wrong forty files looks identical to a rename that did not run.

Nothing changed: then check what the tool is allowed to touch

If the scope is right and still nothing happened, the next suspect is not the file and not the folder. It is the app doing the renaming, and whether macOS has granted it access to that location.

Any renaming tool distributed through the App Store runs sandboxed, which means it has no access to a folder until the user hands it over. Renamer's own support page states that its App Store build will ask for permission to rename files because of macOS security requirements, while the direct download behaves differently. A prompt that was dismissed weeks ago, on a different folder, is invisible today: the app simply does nothing and reports nothing.

Three places control this, and they are separate from each other. Files and Folders in Privacy and Security lists per-app access to Desktop, Documents, Downloads and removable volumes. Full Disk Access is a broader grant that some tools require to reach anything outside those. Automation governs whether one app may drive another, which is what breaks Shortcuts and AppleScript-based renames specifically: the script runs, Finder refuses the instruction, and the error surfaces as silence.

Some tools make this visible rather than silent. NameChanger, for instance, greys out the rows for files it does not have permission to change, so the answer is on screen before the rename button is pressed. Where a tool does not show it, the fastest test is to copy two of the files to a folder the app certainly can reach, such as a new folder on the Desktop, and run the same rule there. If it works on the copies, the problem is access, not the rule.

Some files changed: find the ones that did not

When part of the set renamed and part did not, the answer is in the remainder. Getting a precise list of it is one command, run before and after.

cd ~/Documents/scans
ls > /tmp/before.txt

After the run, produce the same list and compare:

ls > /tmp/after.txt
comm -12 /tmp/before.txt /tmp/after.txt

What comm -12 prints is every name that exists in both lists, which is exactly the set that did not change. Ten seconds of work replaces scrolling through a window trying to spot old names among new ones.

Then look at what those files have in common. Files still holding a cloud placeholder rather than real bytes need downloading before they can be renamed, and a large selection often stalls on the first of them. Files open in an application may be refused by some tools and not others. Files whose new name would exceed 255 characters fail individually while everything shorter succeeds. Files whose new name collides with a name already in the folder are refused by Finder and by careful tools, and silently overwritten by a plain mv.

One category of leftover is not a leftover at all. Each file carries a flag that hides its extension in Finder, and Finder settings hold a global switch for the same thing. With extensions hidden, a rule that only touched the suffix produces a window that looks completely unchanged, and a rule that accidentally rewrote the suffix produces a window that looks fine while the files no longer open. Turning on "Show all filename extensions" before comparing anything removes an entire class of false diagnosis, which is why the ls comparison above is more reliable than looking at the window: the terminal always shows the whole name.

The pattern in the leftovers is the diagnosis. Random-looking leftovers usually mean cloud placeholders. Leftovers that are all the longest names mean the length limit. Leftovers that all share a prefix mean a collision.

Everything changed and the result is wrong

This is a rule problem, and the fix is to stop applying rules to originals.

Replacement in Finder is plain text substitution with no word boundaries, so a rule intended for a year also hits invoice numbers, client names and version suffixes containing those digits. Pattern-based routes have their own surprises: in zsh, zmv -n '(*)2025(*)' '${1}2026${2}' on a file called 2025_2025.txt produces 2025_2026.txt, because the leading wildcard is greedy and reaches as far as it can before the literal text matches. The rule was not wrong so much as it was never read back.

Every route offers a way to read the result before it happens. Finder's sheet shows an example line built from the first item in the selection, updating as the fields are filled. zmv -n prints every planned move and performs none of them. Duplicating the folder with Command+D and running on the duplicate costs a minute on documents, though not on raw video.

Recovery depends entirely on where the rename ran. Command+Z reverses a Finder rename while that Finder session is alive, and it reverses the whole batch rather than one file. Most paid renaming tools keep their own undo list, which survives longer. The terminal keeps nothing at all, which is why the ls > before.txt habit above is worth more than it looks: a saved list of old names makes any rename reversible by hand, and it is one command.

Everything worked and something else broke

The rename succeeded and an hour later a design file reports missing links, a script exits with a path error, or a shared link returns nothing. Nothing is wrong with the folder. Something that stored the old path never heard about the change.

Aliases generally survive, because macOS tracks the file by an identifier as well as by path. Symbolic links do not: they hold a literal string, and that string now points at nothing. Catalogs in photo and design applications hold their own database of paths, and the fix is inside that app, through its own relink or locate function, rather than in Finder. Cloud sharing links keyed to a path stop resolving. Scripts and configuration files holding hard-coded paths fail at the exact moment they run next, which may be days later.

Two checks cover most of this. Before renaming a folder that other things depend on, search the projects that use it for the old name. After renaming, give Spotlight a few minutes: search results referencing old names are usually indexing lag rather than damage, and re-indexing resolves without intervention.

What to change first

Do the scope count and the preview read every single time, because between them they prevent three of the four failures described here. If the same rename comes back weekly, the thing to fix is not the tool but the repetition: a saved rule sitting beside the folder removes the step where a human retypes a pattern under time pressure. Details of which routes keep a preview and an undo list are set out in Compared with other file managers, and the questions that come up most often are collected in the FAQ. Working with the folder, the terminal and the rule in a single window is the approach Atriens takes.