Where a file actually is
100 min
Two hosts talk the lesson through. The voices are synthetic; the script was written from this lesson and checked against it, and asserts nothing the lesson does not.
- Say what makes a directory different from a file, in terms you could use to explain it to somebody else
- Construct an absolute path and two different relative paths to a particular file on your own machine, and translate one into the other
- Find your own home directory on your own operating system and say what the machine means by "home"
- Predict which addresses to a file stop working after a folder above it is renamed, and say what did and did not change
Type a common word into the search box on your computer, something like notes or budget, and look at the results. If you've owned the machine for more than a year, there is a good chance two of them have exactly the same name.
They're different files. They hold different things. You've no way at all to tell them apart from the name, and the only thing that distinguishes them is where each one sits. Many file browsers tell you which folder a result came from, in smaller grey text under the name or along the bottom of the window. That grey line is the file's address, and this lesson is about learning to read and write it.
It's worth the time, for a reason that has nothing to do with tidiness. Almost every "the computer lost my file" story, every broken link in a document, every backup that silently stopped covering the folder that mattered, and every program that says it cannot find something you can see with your own eyes, is an address problem. Once you can write an address down, those stories stop being mysteries and start being things you can check.
Lesson 1 argued that your picture of a system decides what you do when something goes wrong. This lesson starts building the picture, on the machine in front of you.
What you already need, which is almost nothing
Software Carpentry's shell lesson has taught the material in these next few lessons in thousands of two-day workshops to working scientists, and it states its prerequisite plainly: if you have stored files on a computer at all and recognise the word "file" and either "directory" or "folder", you're ready.1 That's the whole entry requirement, and I'd rather say it plainly than have you assume you're behind.
The two words, by the way, mean the same thing. "Folder" is what the graphical picture calls it; "directory" is what the system calls it, and what every command, error message and manual page you meet from lesson 4 onwards will call it. I'll use "directory" from here on so that the word is familiar by the time something else uses it at you.
The tree
The whole structure is three rules.
A directory contains things. What it contains are files and other directories.
A file contains data and contains no other files.
Every tree has exactly one directory that is not inside anything else. It's called the root, and everything in that tree hangs below it. On macOS and Linux there's one tree for the whole machine; on Windows there's one per drive, which is the first difference worth naming and the only one this lesson turns on.
That's it. Follow those three rules and you get a tree: one thing at the top, branching down, with files at the ends of branches. Real machines have hundreds of thousands of files in one, and the shape never varies.
The difference between a file and a directory is worth saying in a way you could repeat to somebody else, because "a folder holds things" isn't quite enough. A directory's content is a list of names. A file's content is the thing itself. When you open a directory you're reading its list; when you open a file you're reading what somebody put in it. That's why a directory can be nearly empty and still exist, and why you can have a directory and a file with the same name in different places and never confuse the machine.
An empty directory and an empty file look much the same in a listing. Say in one sentence what the difference between them actually is, in words you could use on somebody else.
Show the answer
A directory's content is a list of other names. A file's content is data, and it holds no other files.
If your sentence was "a folder holds things and a file is a thing", that is the right instinct and it will not survive contact with the next three lessons, because what a directory holds is the part that matters. It holds names, and that is why position can complete a name, why an address is a walk down a chain of lists, and why a terminal can show you the same list a file browser draws as icons.
Why a tree, rather than one big pile
This is the part that makes the rest follow, so I want to do it properly rather than assert it.
A name is only useful if it picks out one thing. If every file on your machine lived in one enormous list, every name would have to be unique across the whole machine. Think about what that means in practice. You could never have two files called notes.txt. Neither could any program: two applications that both want a file called config would have to negotiate with each other, and with every application written since. Every piece of software on the machine would need to know the name of every file on it.
That's impossible, so systems buy uniqueness a different way. A name only has to be unique among its siblings. Two files called notes.txt are different files because they sit in different directories, and the full address, position plus name, is what has to be unique.
One wrinkle, since you may go looking for the edge of this. macOS and Windows usually treat Budget.xlsx and budget.xlsx as the same name and will not let you keep both side by side; Linux treats them as two different names. Same rule about siblings, different idea of what counts as the same name.
One sentence, and look at how much it explains.
It explains why folders exist at all, and it isn't tidiness. It explains why moving a file changes its address while changing nothing about the file. It explains why two programs can both keep a file called config and never collide. And it explains the thing that trips up everybody sooner or later: the name on its own isn't an address, so any time you tell somebody a file's name and nothing else, you haven't told them where it is.
One exception is worth knowing exists, because you have met it without a word for it. A shortcut on Windows, an alias on macOS, or what Linux calls a symbolic link, is an entry in one directory that points at a file living somewhere else. It's a second address for one file rather than a second file, and it's why something can appear to be in two places at once.
A machine has two files called report.docx, one of them yours and one downloaded from an email. You move yours into the same directory as the other. What does the system do?
Show the answer
In a file browser it refuses, or it asks, or it keeps both by adding a number, which Finder writes as report 2.docx and File Explorer as report (2).docx. What it can't do is keep both under the same name in the same directory, because then the address wouldn't pick out one thing, and an address that names two things is not an address.
Those are the graphical answers, and they are the polite ones. At a terminal, which lesson 4 gets to, the same move usually replaces the old file without asking and with no way back. Same rule, no safety net, and worth knowing before you get there.
That small annoyance you have met a hundred times is the uniqueness rule showing itself, which is why no amount of better software will make it go away.
Your home directory
Somewhere in that tree is one directory that the machine considers yours. Everything you make lives inside it unless you go out of your way, and it has a different address on each of the three systems.
On macOS it is /Users/ followed by your account name, so /Users/tomas.
On Linux it is /home/ followed by your account name, so /home/tomas.
On Windows it is C:\Users\ followed by your account name, so C:\Users\tomas.
Three spellings of one idea. Two differences are worth naming now, because they will come back in lesson 4 and it is better to meet them here where nothing depends on them.
The separator between parts of the address is a forward slash / on macOS and Linux and a backslash \ on Windows. And Windows starts its address with a drive letter, C:, where the other two start at a bare /. Windows has a root per drive; macOS and Linux have one root and attach other disks to a position inside it. Nothing in this lesson turns on the difference, but it is the reason a path copied from one system into another so often produces a shrug.
Why does the machine give you a home directory at all? Because a computer with more than one account on it needs somewhere that belongs to each, and because the system's own files have to sit somewhere you cannot damage by accident. Your home directory is the part of the tree you own. Most of the rest of it you can read and cannot change, which is a piece of the picture that lesson 9 will need when it asks what an administrator password actually grants.
Take 5 minutes now, before reading on. Open your file browser, find your home directory, and write its full address down on paper.
On macOS, open Finder, then Go, then Home. On most Linux desktops the file manager opens at home already, and Control and L shows the address as text you can copy. Windows is in the callout below.
Then make the address visible rather than guessing it. On macOS, with the window open, press Command, Option and P together to show the path bar along the bottom. That path bar is a row of folder names reading left to right, starting with the name of your disk rather than with /, so it shows you the shape without giving you the address in the form this lesson teaches. To get that, control-click the last folder in the row and choose Copy as Pathname.
Write down exactly what it says, including the capital letters. You'll use it three more times in this lesson.
Three things, and none of them changes the idea.
The separator is a backslash. C:\Users\tomas\Documents, where macOS and Linux write /Users/tomas/Documents. That's why a path copied from one system into another so often produces a shrug.
There's a root per drive. Windows addresses start with a drive letter, C:, and each drive is its own tree. macOS and Linux have one root and attach other disks to a position inside it.
Getting to your home directory takes a different route. Your user folder appears in the File Explorer sidebar only if you have turned on View, then Show, then Navigation pane, then Show all folders, which is off by default. The route that always works: open File Explorer, click into the address bar at the top, type %userprofile% and press Enter. You are now in your home directory, and the address bar shows you where it is.
One file, three addresses
There are two kinds of address and you need both.
An absolute path starts at the root and names every directory down to the file. It's unambiguous, and it means the same thing typed anywhere on that machine.
A relative path starts from wherever you happen to be standing. It's shorter, and it means nothing at all unless you know the standing point.
Here is a small tree belonging to somebody called Tomas, with one file marked, and two different places you could be standing when you name it.
Three things to notice.
The absolute path begins with /, which is the root. Reading it left to right is a set of instructions: start at the top of the machine, go into Users, go into tomas, into Documents, into letters, and there is the file. Every step is named, so nothing is assumed.
The relative path from A has no leading /, and that is the visible difference between the two kinds. It says: from where you are, go into Documents, then letters, then the file. Shorter, and useless to anybody who doesn't know you're standing at tomas.
The relative path from B opens with .., which is a name that means the directory one level up. Standing in invoices, .. is Documents, so ../letters/landlord.md reads as: go up one, into letters, then the file. You will also meet ., a single dot, which means the directory you are standing in right now. It looks redundant and it isn't. You'll meet it again in lesson 4, and the reason it earns its place lands in lesson 6, when you find out where the shell actually looks for a program.
Standing at B, write two more addresses: one for the Pictures directory, and one for tomas itself.
Show the answer
../../Pictures for the first. From invoices, one .. puts you at Documents, a second puts you at tomas, and then Pictures is a step down from there.
../.. for the second, which looks odd on the page and is perfectly ordinary. An address is allowed to name a directory rather than a file, and it is allowed to end on a step upwards.
If you wrote /Users/tomas/Pictures instead, that is also correct and it is a different kind of answer: it is absolute, so it does not depend on standing at B at all. Both are right. Which one you want depends on whether the thing reading the address will be standing where you think it is.
The question that shows what each kind is for
Take the file in that diagram, and ask: which of those three addresses still identifies the file if I email it to you?
The answer is none of them, and working out why is worth more than the rule.
The relative ones fail immediately, because you're not standing at A or B, and ../letters/landlord.md on your machine means whatever is one level up from wherever you happen to be. It will either name nothing or, more alarmingly, name some completely different file.
The absolute one feels like it should survive, and it doesn't, because there's no tomas in your tree. An absolute path is unambiguous within one tree, and your machine is a different tree. This catches people constantly: somebody sends a path instead of a file, or a program on a shared drive stores an absolute path that only made sense on the machine it was set up on.
So the honest version of the rule is this. A relative path travels well between positions in the same tree, as long as the standing point is known. An absolute path travels well anywhere in one tree. Neither travels between machines. What travels between machines is the file itself.
The rename that breaks everything and damages nothing
Now the case that teaches more than any other, because it separates the file from its address cleanly.
Tomas renames Documents to Docs. He does it in the file browser, one click, a few keystrokes. He doesn't open anything inside it. Four hundred files are in there and not one of them is touched.
What just happened?
Nothing at all happened to landlord.md. It wasn't read, not copied, not moved. Its content is identical to the byte. If you were looking at it in an open window, the window would carry on showing it.
And yet /Users/tomas/Documents/letters/landlord.md now names nothing. So does every other absolute path that ran through that name, all four hundred of them. The backup script that was told to copy /Users/tomas/Documents will run tonight, find nothing there, and may well report success, because it copied everything it was asked to copy and it was asked to copy nothing.
Tomas is standing at B, in invoices, with ../letters/landlord.md written down. Does that address still work after the rename?
Show the answer
Yes, and this is the case where relative wins. The address says "go up one, then into letters", and the directory one level up is still one level up whatever it is now called. The rename changed a label, and the relative path never used that label.
Which gives you the practical shape of the trade. Absolute paths survive you moving around and break when anything above the file is renamed or moved. Relative paths survive renames above the standing point and break when you are standing somewhere else. Neither is the safe one, and knowing which failure you are exposed to is the actual skill.
This one mechanism is behind a surprising share of everyday breakage: the link in a document that stops resolving, the photo that vanishes from a presentation, the program that used to find its data and now does not, the sync that silently stopped covering a folder. In almost every case nothing was lost. Something above it was renamed or moved, and the address stopped matching.
It is also why "I found it, so it was not lost" and "the address is wrong" are two different diagnoses, and lesson 3 is entirely about telling them apart.
What people get wrong
"The file lives in the program I made it in." People say they will "look in Word for it". Word isn't a place; it's a program that opens files sitting somewhere in the tree. This belief is common enough that in 2021 The Verge published a piece reporting university instructors who found students unable to say where their work was saved, and, in the reporter's framing, not understanding the question.2 I've read that article at summary level rather than in full, and I want to be careful about what it is: it is journalism about a teaching experience, and it cites no study measuring how widespread this is. So don't take from it that a generation cannot use folders. Take from it only that the belief exists and is worth teaching against, which is a much weaker claim and enough for our purposes.
"The desktop is a place." The desktop is a directory. Ordinarily it sits directly inside your home directory, and you can see it in a minute: open your file browser, go to your home directory, and there it is, alongside Documents and Downloads. Anything on your screen is in that directory.
There's one common exception, and it makes the point rather than spoiling it. If OneDrive on Windows or iCloud Drive on a Mac has been set to look after your desktop, the directory has been moved into the sync folder, and what you are looking at on screen is the contents of a directory somewhere else in the tree. It's still a directory. It just isn't the one you expected, which is exactly why knowing the address matters. If you go looking and your home directory has no Desktop in it, that's what happened.
This matters for a practical reason. People treat the desktop as somewhere outside the filing system, back it up separately or not at all, and are surprised when it behaves like the ordinary directory it has always been.
"Search means I do not need structure." Search and structure answer different questions. Search finds what you can name. Structure finds what you have forgotten the name of, which is most of what you go looking for from more than a month ago. Lesson 3 takes that apart properly, because it turns out to be the same problem as a file going missing.
"The cloud folder is somewhere else." Your synced folder is a directory on this machine, in the ordinary tree, with a program watching it and copying changes to a server. It isn't a window onto a distant place. That isn't a technicality; it's the fact lesson 12 is built on, because a program that faithfully copies whatever is in that directory will faithfully copy the damage as well as the work.
"If I cannot see it in the folder, it is not there." macOS and Linux hide files whose names begin with a dot. Windows hides whatever has been marked hidden, which is a flag on the file rather than a shape of its name. Either way, your view of the tree is a filtered view, every system has a setting that unfilters it, and the things it hides are mostly configuration files that programs keep for themselves.
Practice
Take 20 minutes. Do it on the machine, not from memory, and write your answers down rather than thinking them.
Pick a file you made at least a month ago and can still find. Open your file browser at the root of your drive, and walk down to it without using search. Write down the name of every directory you pass through, in order.
Getting to the root is not obvious on any of the three, because none of them puts it in front of you. On macOS: Finder, then Go, then Computer, or press Shift, Command and C. On Windows: This PC, then Local Disk (C:). On GNOME Files: Other Locations, then Computer.
From that list, write the file's absolute path. It is your list with separators between the parts and the root at the front, so you have already done the hard bit.
Now write two relative paths to the same file, from two different standing points. Choose standing points that are genuinely different: one above the file, and one in a sibling directory so that your answer needs at least one
...Beside each relative path, write the standing point it assumes, in a sentence. If you can't state the assumption, the address isn't finished.
Answer this in writing: if you renamed the directory two levels above the file, which of your three addresses would still work, and why?
Take 15 minutes over this one. It's the more useful of the two, because it's the one that finds the gaps in your own picture.
Open your Downloads directory and your Desktop, and look at how many items are in each. Write the two numbers down without judging yourself.
Find one file whose position you did not choose, or did not know about. Candidates: something a program saved for you, something an installer left behind, an export from a phone app, a screenshot.
Write its absolute path, and then write one sentence on why it is there. Not where you'd have put it. Why the thing that made it put it there.
Now decide, in writing, whether it should stay where it is. Give a reason either way. Lesson 3 covers the case where moving it breaks something, so if you are unsure, leave it and note the question.
Connections
Lesson 1 said that your model of a system decides what you do when something goes wrong. Now you have the first piece of a real one, and you can test it against the tree on your own machine, where the places it does not match are worth more to you than the places it does.
Lesson 3 takes the same tree and looks at the names in it: what a file extension does and does not tell you, why plain text is not the same as a document, and the five reasons a file goes missing, three of which are address problems you can now state.
Lesson 4 opens a terminal, which is the same tree addressed differently, and the paths you have just written are the ones you will type. Everything in lesson 4 depends on this one, which is why you have been writing addresses by hand rather than reading about them.
Lesson 12 needs one sentence from here: a synced folder is a directory in this tree with a program watching it.
Go deeper
- Software Carpentry, The Unix Shell, episode 2, "Navigating Files and Directories". Free, CC BY licensed, and the best-tested version of this material anywhere. It does the same tree from a terminal rather than a file browser, which is where lesson 4 is going, so reading it now is a head start rather than a repetition.
- The Verge, "File Not Found", Monica Chin, 22 September 2021. Read it as a piece of reporting about how teaching has changed, not as evidence about a generation. The instructors' descriptions of the conversations they had are the interesting part.
Sources
- Software Carpentry, "The Unix Shell" (shell-novice), swcarpentry.github.io/shell-novice, CC BY 4.0. Lesson homepage, episode 2 "Navigating Files and Directories" and the instructor notes read in full. Supplies the stated prerequisite paraphrased at the top of this lesson, the file-and-directory framing, the construct-a-path objective this lesson's exercises are built on, and the recommendation to keep the file browser and the terminal side by side, which lesson 4 uses.
- Monica Chin, "File Not Found", The Verge, 22 September 2021. Read at search-summary level; the article itself was not opened. Supplies only the existence of the reported phenomenon, and the lesson says so and draws no prevalence claim from it.
Check your understanding
This lesson has a 6-question quiz. Pass it and the questions come back on a schedule in Review, so what you learned stays learned. Your progress is saved in your browser; no account needed.