As is the case with most simplified explanation, I have glossed over some more advanced specific details that don't factor into the basics on file systems.
At its most basic level, a file is really just a sequence of ones and zeroes. It's data. There's nothing more to it than that.
This data can then be interpreted. We (or an application) take the ones and zeroes, attribute meaning to them, and this interpretation is informative to us (or an application).
"Interpretation" is the operative keyword here. The same arbitrary sequence of ones and zeroes can be interpreted in any way you want to. However, in most cases only one interpretation will make sense, and other interpretation will look like garbage.
So how do we know which interpretation should be used for which file? Answer: the file extension. A file extension denotes how the data in the file is structured, and therefore how it can be sensically interpreted.
Your OS automates this process for you. Instead of you having to look at the extension and then find the correct application which can interpret your file in the way you need it to be interpreted, your OS automatically maps a given file extension to your preferred application. For example, you might configure Windows to open
.txt files with WordPad, or Notepad, or Notepad++, or some application you wrote yourself. All of these application are capable of performing the interpretation that a
.txt file needs.
You can override this behavior. You can open a
.png file in Notepad. It won't make sense, but what you are seeing is the result of a
.txt interpretation being applied to a file whose data structure is that of a
.txt files are very easy to interpret. Ignoring encoding for now (let's assume ASCII), every byte (= 8 bits) of the ones and zeroes represents a single number, which in turn represents a single character.
To really prove the point, you could do this manually. Let's say I want to store a text file containing
apple. You can use an ASCII table to look up what the numeric representation of each character is.
a = 01100001
p = 01110000
p = 01110000
l = 01101100
e = 01100101
If you use your text editor of choice, set the encoding to ASCII, enter
apple and save the file, the file's ones and zeroes will exactly be the sequence of binary digits I just listed.
.txt is really easy, but file structures can get significantly more complex, to the point where it is no longer feasible for a human to manually interpret all the data. For example, even though a
.pdf file might only contain text (to your eyes) just like a
.txt, it actually stores a whole lot more data (text markup, file metadata, ...) and this makes it less than obvious to interpret the binary data ourselves.
But to prove the point on how you can interpret files in a non-text example, suppose you (as a teacher) want to track whether your students were present/absent every day of school. Assuming you have 16 students, you could track this using a very simple sequence of 16 binary digits:
Everyone was present that day, except student 11.
Is this a good file format? Well, it's very efficient. But it also lacks context. There's an assumption on which students were in your class. There's no way to track justified absences, etc. To really cover all the information you need, you're going to need a more complex system. But if you assume a simple present/absent mark for a fixed list of students, the above file format could theoretically suffice.
Take an existing Word/Excel file, one with an "x" in the file extension (
.xlsx). Change its file extension to
.zip and try to open it. It... works!?
Since the advent of the new Office file formats, Word and Excel documents are really just secret zip archives, not custom binary file formats like they used to be. But by using a unique file extension instead of
.zip, people can still configure these
.xlsx files to be automatically opened using Word/Excel instead of however they've configured
.zip files to be opened.
File name (and path)
At its most basic level, a file name is just one long string of characters, nothing more.
Obviously, we're likely going to want to store more than one file on our computer. So we need a way to reference each file that we store. This is why we give them a name, to tell them apart. This is no different from why humans give eachother names.
As mentioned before, we add a file extension to the end of the name, so that we remind ourselves (and the OS) of the data structure that was used for the file content.
But we often have a lot of files. We'd really like to organize them properly into little collections, instead of throwing them all on one big messy pile. To do this, we started prepending our filenames with what we call the "path".
A path is nothing more than a (back)slash-separated sequence of names which list the hierarchy of how we'd like to organize our files. The OS will take the file name, split the names into the separate chunks, and will use that hierarchical information to show your files in a neat and organized manner.
Every file's name is really just a combination of:
[folder chunks][name of the file].[file extension]
Take the example of the following file names:
If you split the names in the chunks between the backslashes, you can start seeing the structure. For example, the first and third file have exactly the same chunks before their file name. Therefore, they belong in the same folder. The second and fourth file have a common first chunk, but then they have a different chunk. Therefore, they are found in the same parent directory but then live in a different subdirectory.
If you apply this logic, just like how an OS does, you come up with the intended organisational structure:
│ ├─ apple.txt
│ ├─ banana.txt
│ ├─ PeopleIHate/
│ │ ├─ Kevin.png
│ ├─ PeopleILike/
│ │ ├─ Tom.png
We like to think of our file system as this neat nested system of folders and subfolders. But in the underlying file system, we don't actually store a "folder" by itself. A folder is really just generated dynamically based on the slash-separated chunks found in a file's name.
This leads to some interesting effects:
- Want to move a file? All you have to change is the file's path. You don't need to update a folder itself.
- Want to rename a folder? Then you're going to need to change this name in all of the files who contain this folder in their path.
This is an oversimplification. File systems are more complicated than this, because you need the ability to e.g. create empty folders. But this is a good first explanation of how the file system works.
Next to the file name and content, there's more things we know about the file, such as when it was created, whether it is read-only, any permissions attached to the file, ... These things are not stored in the file content. They are an addendum to the file.
If you transfer a file from one file system to another, this data may be lost if the target system doesn't know how to work with the source system's metadata structure. However, this doesn't matter in terms of using the file itself. Your data is safe. You might just lose track of e.g. when your file was created.