Names, extensions, and the file that went missing

Somebody asks you for a plain text file. You open the writing program you have, type the list, save it, and send it. It comes back rejected. You look at what you sent and it looks exactly like a list of words, so you send it again, and it's rejected again.

That is one of the failures the instructors of the world's most-taught shell workshops record, after a decade of watching it happen in the room.¹ Their version of it is that learners on Windows reach for the writing program they already have, and it doesn't make a plain text file. There is a program on the machine that does, and nobody has told them which one, or why it matters.

It's not a small problem or a beginner's problem. It comes from a single confusion about what a file's name tells you, and clearing that up also explains the wrong program opening your documents, the attachment that wasn't what it claimed, and about half of the times a file goes missing.

Lesson 2 gave you the address. This lesson is about the last part of it, the name itself.

What an extension is, and what it is not

The extension is the part of a file's name after the final dot. .txt, .jpg, .docx, .py.

It is a convention about which program should open the file. That's the whole of it. It isn't a property of the data, it isn't enforced, and it isn't checked. It's a few letters on the end of a label that a person or a program chose.

Before the experiment that settles it, you have to be able to see the thing we're talking about, and two of the three systems are hiding it from you right now.

Now the experiment, and I'd rather you did it than believed me.

What's inside is print("hello"), unchanged, to the last character. In 2026 I ran the same rename on the machine I am writing this on and compared a checksum of the file before and after, which is a way of asking whether a single byte differs. Not one did.²

So the rename changed no data at all. What it changed was a prediction about what the file is, and that prediction is what the icon and the double-click behaviour are made of.

The one indirection worth understanding

Why does the system care about the end of a name?

Because when you double-click, something has to decide which program to start. Systems keep a table: this extension goes to that program. .pdf opens in one thing, .jpg in another, .docx in a third. The table is editable, which is why you can change what opens your photos.

So the name isn't only a label. It is data that the system runs a decision on. That one indirection, name to table to program, explains four things you have met:

The "open with" menu exists because the table holds one default per extension, and sometimes you want a different program for one file without changing the rule for all of them.

The wrong program opening your file is the table being right about the extension and wrong about what you wanted, which is a much less mysterious kind of wrong.

A file can be perfectly good and still be refused, because a program checked the name rather than the contents. And a file can be dangerous while carrying a harmless-looking name, because the name is a claim rather than a fact about the contents.

Which is why hiding extensions costs you something real. The name is not evidence about what is inside a file. It is evidence about what the machine is going to do with it, which is a different thing and a more urgent one, and hiding it takes the system's own reasoning off the screen. The next section is about what that buys an attacker.

Plain text, and the programs that will not produce it

This is the failure the lesson opened with.

Plain text means a file whose content is characters and nothing else. No font, no size, no bold, no page layout. Open it in any editor on any system and you get exactly the characters somebody typed.

That's what a shell needs, what a program's source code has to be, what a configuration file is, and what a great many websites mean when they say "upload a CSV" or "plain text only".

Three programs, and three different outcomes.

TextEdit, on macOS, opens in rich text by default. It saves .rtf, which is a text-based format carrying formatting instructions, and it isn't what "plain text" means. The fix is one menu item, Format then Make Plain Text, and there is a setting in TextEdit's own Settings, under New Document, to make plain text the default. Do that now and you'll save yourself a puzzled hour later.

While you are in TextEdit's Settings, go to Open and Save and tick Display RTF files as RTF code instead of formatted text. Without it, TextEdit opens an .rtf and renders it beautifully, so you see the words you typed and conclude the file is plain text. With it on, you see what is actually in the file, which on this machine begins {\rtf1\ansi\ansicpg1252\cocoartf2870 and buries your sentence about a third of the way down.³

Word doesn't produce a text file at all. A .docx is a compressed archive with a set of XML documents inside it, so a program looking for characters finds a zip header. Word can produce plain text, through Save As and choosing the plain text format, and it'll warn you that formatting will be lost, which is the correct warning and is the whole point.

Notepad, on Windows, does produce plain text. It is the right tool and it is not the one people reach for, which is the failure Carpentry's instructor notes record alongside not finding the home directory and scripts refused for their line endings.¹ The callout below has the line-endings wrinkle, which is real and is not a reason to avoid Notepad.

The five reasons a file goes missing

Now the other half of the lesson, and the good news is that three of the five are things you can already state, because lesson 2 gave you the vocabulary for them.

One: it was moved or renamed. Either one changes the file's address while changing nothing about the file. Every link, shortcut, backup rule or program setting that named the old address now names nothing. This is the commonest cause and the least alarming.

Two: it was saved by a program into its own storage. Photo libraries, note-taking programs, some mail clients and nearly everything that came from a phone keep their content in a directory of their own choosing, sometimes under a name that has nothing to do with your title for it. The file is in the tree, and its position wasn't your decision.

Three: it is in a synced directory that is not currently synced. Your cloud folder is an ordinary directory with a program watching it, as lesson 2 said. If that program is signed out, paused, out of space or unhappy about something, the machine in front of you and the copy on the server are different, and neither of them is wrong.

Four: it went to a default location you never chose. Downloads, a temporary directory, the desktop, or whatever the program had as its last-used folder. The choice was made, just not by you.

Five: it was never given a location at all. It exists only inside a program's unsaved state, which is a real place and a fragile one.

Causes one, two and four are all address problems, and they are not the same kind. In cause one an address that somebody really did write down has gone stale. In causes two and four nobody ever wrote one down; the mismatch is between the position you assumed and the position the file has always had. That is why they feel different to live through and diagnose the same way.

What "search found nothing" is worth

Lesson 2 said search and structure answer different questions. Now you can put a number on how much a failed search actually tells you, which is less than people think.

It rules out nothing on its own. Go back through the five. A failed search is consistent with all of them, because indexing is partial: it covers part of the tree, it reads the content of some file types and not others, and it cannot see a file that is not on this machine today.

It is real evidence about two of them. If the file is an ordinary document sitting in your home directory, which is causes one and four, a search on a word from inside it usually finds it. So a genuine failure there makes those two less likely and pushes you towards three and five, the two the index cannot reach at all.

It says almost nothing about cause two, for the reason the predict block gave: it depends entirely on whether the program keeps ordinary files or one big database.

So the honest reading is: a failed search moves the odds and settles nothing, and the next thing to do is not another search. It is to ask which of the five you are in.

The file that is not missing

The last case needs judgement rather than a rule.

A designer keeps her photographs in a program that manages them for her. She finds the folder it uses. It is a real directory in her home directory, full of real image files, in subdirectories named after dates rather than after anything she would have chosen. She wants them somewhere sensible.

She has three options and only one of them is safe.

Moving it breaks the program. The program holds an address for its library, and lesson 2 told you what a move does to an address. The photographs are entirely unharmed and the program can't find a single one.

Renaming the containing folder does the same thing for the same reason, which is worth noticing because renaming feels gentler than moving and isn't.

Copying out what she wants works, costs disk space, and leaves the program exactly as it was. She now has two copies of some pictures, which she should be deliberate about rather than surprised by.

So: copy out, do not move. But the reasoning is the thing to keep, because it generalises to every program that manages its own storage, and the rule on its own doesn't tell you what to do the day the program is uninstalled and the folder is all that is left.

What people get wrong

"The extension is what the file is." The experiment at the top of this lesson is the answer. The extension is a claim about the file, and claims can be false, by accident or on purpose.

"Hiding extensions makes things simpler." It hides exactly the part of the name that decides what happens when you click. The clearest cost is an attachment named statement.pdf.exe, which on a machine hiding known extensions displays as statement.pdf. The reader sees a document. The system sees a program, and runs it. Lesson 9 comes back to this with the rest of the machinery for deciding what to install; for now, extensions are on, because that was the first thing this lesson had you do.

"A Word document is a text file." It holds your text, which isn't the same thing. If a program asks for text and you give it a .docx, the program gets a zip archive and says something unhelpful about encoding.

"If search cannot find it, it is gone." Search covers part of the tree, indexes some content and not all of it, and can't see a file that isn't on this machine today. "Search found nothing" is evidence, and a weak one.

"Saving is saving." Every program has a default place it saves to, and somebody chose it, and it wasn't you. The most useful habit in this lesson is to look at the folder named in the save dialogue every single time, for about two weeks, until you've a sense of where your programs have been putting things.

Practice

Connections

This lesson finishes the graphical half of the picture. You can say where a file is, write its address two ways, read its name, and work out why it isn't where you expected.

Lesson 4 opens a terminal, which is the same tree addressed by typing, and puts it beside your file browser so you can watch the two views agree. Lesson 5 then has you save a file called hello.py and run it, and that file has to be genuinely plain text or nothing works, which is why this lesson comes before those two rather than after them. The set of commands those two lessons teach is taken from MIT's Missing Semester, a short course that exists because universities skip this material entirely.⁴

Lesson 9 needs the double-extension case from the misconceptions above, and the wider question it raises: what exactly are you trusting when you open something somebody sent you.

Lesson 12 needs two things from here. The third cause of a missing file, a synced folder that is not currently synced, is the first hint that sync and backup are different animals. And "what is actually worth keeping a copy of" is a question you cannot answer until you know where your files really are.

Go deeper

• Software Carpentry, The Unix Shell, and in particular its instructor notes. The notes are not written for learners, which is what makes them worth reading: they are a decade of instructors recording what actually goes wrong in the room, and the plain-text-editor problem is near the top of the list.
• MIT, The Missing Semester of Your CS Education, lecture 1. Aimed at computer science undergraduates rather than at you, so take it at your own pace, but its opening argument is worth ten minutes: universities teach advanced material and leave students to work out the tools alone, even though the tools are what they use for hundreds of hours.

Sources

1. Software Carpentry, "The Unix Shell" (shell-novice), swcarpentry.github.io/shell-novice, CC BY 4.0. The instructor notes read in full. They record what goes wrong on Windows in their workshops: learners not finding the home directory, not having a plain text editor to hand, and scripts refused for their line endings. The notes give no ranking and no counts, so this lesson claims none. The home directory one was used in lesson 2.
2. Checked on the machine this lesson was written on, macOS, September 2026: a plain text file saved as test.txt and renamed to test.py kept an identical checksum and an identical inode. A Unix tool that reads the leading bytes of a file, file, reported both as ASCII text regardless of the name, while macOS's own type table went on believing the extension and reported a 1-pixel PNG named real.jpg as a JPEG. That pair is the point of the section: the name is not evidence about the contents, and it is exactly what the system acts on.
3. Checked on the same machine, September 2026: a rich text file produced by the system's own text engine begins {\rtf1\ansi\ansicpg1252\cocoartf2870 and holds the typed line about a third of the way in, behind formatting instructions. A .docx produced the same way begins with the bytes 50 4b 03 04, which is a zip archive, and unpacking it yields word/document.xml and its companions.
4. MIT, "The Missing Semester of Your CS Education", missing.csail.mit.edu, CC BY-NC-SA. Homepage and the 2020 edition's lecture 1 notes read in full. Supplies the course's own statement of why this material is skipped, linked above as further reading, and the scope of commands that lessons 4 to 6 draw on.