File naming conventions not working: what to check, in order

Three unrelated faults get reported with the same sentence: the naming rule is not working. In the first, the name on screen is not the name stored on disk, so nothing matches it. In the second, every name is correct and the folder still lists in an order nobody expects. In the third, the rule is written down and half the folder has never followed it. The usual first move, rewriting the rule and renaming everything in one pass, fixes one of those three and quietly makes the other two harder to see. Splitting the symptom takes about a minute and turns a vague complaint into a short list of commands.

Split the complaint before changing anything

Open the folder that prompted the question and run one test for each of the three.

Is the name what it looks like? Open Terminal at that folder and run ls. Compare what it prints, character by character, against what Finder shows in the same window. If a character differs, or a name prints with something at the end that is not visible in Finder, the fault is in the stored name and nothing further up will work until that is settled.

Is the order wrong rather than the names? Sort the folder by Name in Finder, then run ls on the same folder. If the two lists disagree, the names are probably fine and the disagreement is the whole problem.

How many files did a person name? Look at the twenty most recent arrivals and mark each one as typed by a person or written by a device or a download. If most of them are the second kind, the rule is not failing. It was never reaching those files.

These three point at different layers: the stored name, the sort, and the point of arrival. Working them in that order matters, because a fix applied at the wrong layer looks like it worked until the next batch of files lands.

The name on screen is not always the name on disk

Finder shows a display name. ls shows the stored name. They are usually identical, and the cases where they are not account for a large share of "the file is there but nothing finds it".

The clearest example is the forward slash. The POSIX layer of macOS refuses to store one inside a name, so Finder accepts the keystroke and writes a colon in its place. A file typed in Finder as 2026/09/12_invoice.txt is stored as 2026:09:12_invoice.txt. Finder keeps displaying the slash, so the substitution is invisible until a script, a sync client, or an archive tool reads the real name and finds a character that is not in the rule. A rule written with slashes in the date will therefore appear to be followed perfectly and match nothing.

Spaces at the end of a name are the second case. They are stored, they are legal, and they are invisible in every graphical listing. Piping the listing through a filter that marks the end of each line exposes them. ls | sed -n l prints a dollar sign after the last character, so a name that ends in a space shows as 提案書_v2 $ instead of 提案書_v2$. A single trailing space is enough to make an exact match fail, and it is easy to introduce by pasting a name out of a spreadsheet cell.

The third case only appears when files have travelled. Volumes formatted as HFS+ store names in decomposed form, so が is held as か followed by a combining mark, while APFS stores whatever was typed. Both spellings render identically. Compared as strings they are different, which is why a script that matched every file in a folder can match none of them after the same files have been copied to an older external drive and copied back.

Reading the stored name directly

When a name looks correct and still fails to match, print its bytes rather than trusting the screen. A short command that lists the folder and normalises each entry is enough to show whether two visually identical names are actually two different strings. Once that answer is known, the repair is a single rename, and the more useful outcome is knowing which route into the folder introduced the difference.

Three routes account for most of it. Copying to a volume formatted as HFS+ and back, which rewrites names into decomposed form. Pasting a name out of a spreadsheet or a chat message, which brings along whatever whitespace and punctuation the source had, including full width characters that look like their ASCII equivalents and are not. And typing a name in Finder that contains a character the stored name cannot hold, which is the slash case above. Knowing which of the three applies decides whether the fix is a one off rename or a change to how files enter the folder.

It is worth recording the answer somewhere the next person will find it. A folder that has already been through this once will go through it again when a new drive, a new scanner, or a new colleague arrives, and the second investigation is the expensive one because nobody remembers that it was settled before.

Everything is named correctly and the order is still wrong

If ls and Finder disagree, the names are almost certainly fine. Two sort rules are in play and both are behaving as designed.

Finder compares names the way a person reads them, so a number inside a name is treated as a number. ls compares character by character, so the number is treated as text. The same six files come out in two different orders.

Files	Finder order	ls order
会議資料1, 2, 9, 10, 11, 100	1, 2, 9, 10, 11, 100	1, 10, 100, 11, 2, 9
Padded to three digits	001, 002, 009, 010, 011, 100	001, 002, 009, 010, 011, 100

Padding the number ends the disagreement, and it is the only fix that holds in both tools at once. Three digits covers a folder, four covers a daily sequence across a year. Version markers have the identical defect, so v2 and v10 need to be written v02 and v10.

Two other things produce an order that looks broken when it is not. A name beginning with a space or a punctuation mark sorts ahead of everything, which usually means someone pasted a name with leading whitespace. And a Finder window set to sort by Date Added rather than Name will ignore the naming rule entirely, which is worth ruling out before anything is renamed, because it takes one click to check and one click to undo.

The rule holds for some files and not for others

This is the symptom that renaming cannot fix, because the folder contains two populations rather than one broken population.

Files a person saves deliberately carry the rule, since a person is present and thinking about the name. Files that arrive by any other route carry whatever their source produced. A download keeps the server's name. A scanner writes its own counter. A camera writes DSC and four digits. An attachment saved out of mail keeps the sender's convention. A screenshot gets a timestamp in the system format, which is a different format from the one in the rule.

Counting is better than guessing here. Mark thirty consecutive arrivals by origin and the split is usually obvious, and it points at which single capture point is worth changing. Fixing the scanner template once removes more exceptions per hour of effort than any amount of renaming after the fact, because it stops producing them.

Where the arrivals cannot be fixed at source, the choice is between renaming everything that lands or renaming nothing. A half applied rule is the worst of the three, because neither browsing nor searching returns a complete set and there is no way to tell which kind of failure is in front of you.

When the rename itself refuses to run

Sometimes the rule is fine and the rename stops partway through. Four causes cover nearly all of it.

The name is too long. A name component on APFS holds 255 units. That is 255 ASCII or Japanese characters, but only 127 emoji, since each emoji counts as two. Going over does not shorten the name. The operation fails with "File name too long", and while some tools show that message, others skip the file and report success for the rest. A long descriptive rule should be tested against its longest realistic case before it is adopted.

Two names collide on case alone. The default startup volume is case insensitive, and the collision is silent. Renaming two.txt to ONE.TXT in a folder that already holds One.txt leaves one file, still called One.txt, containing what used to be in two.txt. Nothing is printed, nothing is asked, and the original contents are gone. Any rule that distinguishes two documents by capitalisation alone works on a case sensitive server and loses files on a Mac.

The item is locked. A locked file returns "Operation not permitted" on rename, which reads like a permissions fault and is not one. Clearing the locked state in the Get Info window is enough.

Permissions or an active process. A file inside a folder you cannot write to will not be renamed regardless of who owns the file, and an item held open by a running application can fail intermittently, which looks random until the pattern is noticed.

The order to check in

Working these in sequence avoids repeating the same repair three times.

• Compare ls output against the Finder window and settle whether the stored name matches the visible one
• Reveal invisible characters with ls | sed -n l before concluding a name is correct
• Check the Finder sort setting, then compare the two sort orders, and pad numbers if they disagree
• Count the last thirty arrivals by origin and identify the capture point producing the most exceptions
• Only then rename in bulk, and test the rule against the longest name in the folder first

One practical note on the first three steps. They involve looking at a folder and running a command against the same folder in the same breath, which is two windows and a path that has to be retyped or dragged. A file manager with a built-in terminal collapses that into one, and the Compared with other file managers page sets out which tools do this and which do not.

What to change first

Run ls on the folder that prompted the question and read it against the Finder window before touching a single name. Whichever of the three symptoms that reveals, fix that layer alone and let the next batch of files arrive before deciding whether anything else needs doing. Atriens is one way to keep the listing and the command in one place while working through it.