The Files You Cannot Type

There is a file on your old Macintosh disks that you have almost certainly never seen, cannot create, cannot rename, and — if you have ever dragged a folder between disks and wondered why its lovely custom icon turned back into a plain manila rectangle — have probably destroyed.

It is called Icon, and it ends with a carriage return.

A folder with no pockets

Here is the problem Apple had to solve. On a classic Mac, everything interesting about a file lives in its resource fork — its icons, its dialogs, its sounds. A folder, though, is not a file. It is a row in the catalog B-tree. It has a name, a parent, some dates and a fistful of flags, and nowhere at all to put a picture.

So when System 7 let you paste a custom icon onto a folder, that icon had to go somewhere. Apple’s answer was elegantly boring: put it in a file, inside the folder, and make the file invisible.

Which raises an obvious question. If the Finder is going to rely on a file named Icon being its file, what happens when some user innocently creates a document called Icon?

The trick

Apple named the file Icon followed by a carriage return — byte 0x0D.

Rename Icon

↵ Return

Press it and you commit the name. The keystroke never reaches the text.

You cannot type that. Press Return in the Finder’s rename field and you commit the name; the keystroke never reaches the text. There is no modifier, no escape hatch, no Option-key incantation. The name is simply unreachable from the keyboard, which makes it unforgeable, unrenameable, and impossible to collide with by accident.

It is the same instinct as a leading dot on Unix, except a dotfile is merely a convention politely observed. Icon\r is enforced by the input method. You are not being asked not to create one. You are being prevented.

And it works because classic Mac filenames are not strings. An HFS name is a Str31 — a length byte followed by raw bytes, no terminator — and the only reserved character is :, because that is the path separator. Every other byte in the range is legal. Carriage returns, tabs, nulls, anything. The length byte says how many, and the file system does not care what they are.

“That smells like an artefact”

When we first saw Icon\r come out of a disk image, the reasonable reaction was suspicion. A trailing carriage return on a filename looks exactly like something a tool appended — a line ending that escaped from a text stream and glued itself to a name.

There is a clean way to settle it, and it does not involve trusting anybody’s memory. HFS stores each catalog entry behind a key, and the key carries its own length. For a record whose name is Icon plus a CR, the arithmetic has to work out as:

11 = 1 + 4 + 1 + 5

keyLength reserved parent ID name length name bytes

Eleven. Not ten. And on real media, that is exactly what it reads — with the name’s own length byte independently saying 5, and the record type byte following it reading cdrFilRec, an ordinary file record. Two separate fields, measured on different parts of the structure, agreeing that there are five bytes in a name spelled with four letters.

The carriage return is really there. It has always been there. It is the point.

It is not one file. It is a namespace.

Having established the trick, the obvious next question is whether Apple used it more than once. So we swept a corpus of classic disk images — 47,874 catalog entries, after excluding Finder aliases, which mirror real files and will happily ruin your statistics if you let them.

410 names carried a carriage return. 406 of them — 99.0% — were deliberate.

Name	Count	What it is
Icon\r	386	Custom icons, for folders and volumes
OpenFolderListDF\r	14	Which folders you left open
Date Preferences\r	3	Shipped by a Microsoft installer
everything else	4	Leading CR, not trailing — see below
Total carrying a carriage return	410	out of 47,874 entries swept

OpenFolderListDF\r is the Finder remembering which folders you left open. Date Preferences\r came along with a Microsoft installer. Same trick, same reason: a file the system owns and the user cannot touch.

That leaves four entries unaccounted for. Two specimens, as it turns out — and both carry their carriage return at the front, not the back.

One is a Japanese ClarisWorks 1.0v4 StuffIt archive containing a file called \rインストーラ — “Installer”, with a leading carriage return. Tellingly, the same archive also holds an ordinary folder named インストーラ with no CR at all, sitting right beside it. The other is a disk somewhere in the world containing a file called \rchristmaaaaa, which accounts for three of the four entries because the same disk survives in three image formats, and which we are choosing to believe was somebody’s very good afternoon in 1993.

The distinction matters, though. The convention works precisely because the byte is last. A leading control character is just an odd filename. A trailing one is a lock.

Meanwhile, in Arabic

Here is where it gets genuinely interesting.

If you open an Arabic System 6 disk — a real one, مجلد النظام, System Folder, 1989 — you find twenty-one files. Most of them are in Arabic, exactly as you would hope. The control panels, the extensions, the help file, the calendar, the sound: all localised, all beautiful.

And then, sitting among them in plain Latin script:

Localised

• الباحث المتعددMultiFinder
• الألوانColours
• الصوتSound
• التقويمCalendar

Untouched

• Systemboot block field
• Finderboot block field
• Clipboard File
• International

Even MultiFinder got translated — it is there as الباحث المتعدد. But Finder itself did not. Neither did System.

Why? Because those two names are not really filenames at all. They are fields in the boot blocks — the first 1,024 bytes of every bootable Mac volume, in a structure that begins with the signature LK (for Larry Kenyon, who wrote the file system, which is a lovely thing to find sitting at offset zero of a forty-year-old floppy). Two of those fields are bbSysName and bbShellName, and they contain, as literal text:

1. 0x00 bbID — ‘LK’ 0x4C 0x4B — Larry Kenyon
2. 0x0A bbSysName Str15 6System read by the ROM at boot
3. 0x1A bbShellName Str15 6Finder read by the ROM at boot
4. 0x2A bbDbg1Name Str15 7MacsBug and yes, the debugger too

Str15 stride is 16 bytes — one length byte plus fifteen characters — which is why the fields land 16 apart.

The ROM reads those strings at boot, long before anything as sophisticated as a script system has loaded. There is no localisation layer yet. There is barely a Macintosh yet. So the names cannot be translated without breaking the machine’s ability to start.

We checked Hebrew and Yugoslavian installers too. Same bytes. System, Finder, six characters each, no carriage return in sight — because a Str15 field is already length-prefixed and has nothing to terminate.

Two kinds of special

Which gives us two entirely different mechanisms wearing similar hats:

Invariant by structure

System  Finder

Baked into the boot blocks. You may absolutely create a file called System if you like — it is a perfectly legal name — it just will not be the System.

A fact about the boot process

Protected by unforgeability

Icon\r  OpenFolderListDF\r

Nothing structural stops you creating one. You simply cannot, because the keyboard will not let you.

A fact about the input method

One is a fact about the boot process. The other is a fact about the input method. It is a nice illustration of something classic Mac OS did constantly: solving a problem in the layer where it was cheapest, and letting the consequence become the convention.

And the thing we still do not know

Inside Macintosh — all six of the original numbered volumes — documents the custom-icon resource perfectly well. It tells you the resource ID (kCustomIconResource = -16455, since you ask). It tells you about the hasCustomIcon flag bit.

It never explains how a folder gets one.

The chapter is written entirely about files, which have resource forks, and it simply does not address the case of the thing that does not. The Icon\r convention — the actual mechanism, the thing every Mac was doing millions of times a day — appears in none of the six volumes we can search.

It may well be in the revamped series, in Inside Macintosh: Files. We would love to tell you. Unfortunately our only copy is on a 1995 CD-ROM, in Apple’s own long-dead DocViewer format, which no modern application can open.

But that is a story for another post.

---

This came out of work on Disk Phoenix, which reads, repairs and rescues classic Macintosh disk images. The census above is real, the Arabic disk is real, and yes, we did go and fix the code that was cheerfully deleting people’s folder icons.