What is a file?

Question

I recently had a student in my Intro to CS class ask me: what is a file? I can't honestly say I had a good answer for him. Those of us who have been around a while know what a file is, but I was at a bit of a loss to explain it to a novice.

Today's students believe (and rightfully so) that a file is an icon-thingy in a folder or on the Desktop. They have some vague idea that there are files for images (JPEG, GIF, PSD, etc.), files for music (MP3, WAV), files for doing office stuff (docx, pptx, etc.), and maybe even HTML files. But they don't know what's in a file. That's where I kind of stumbled around for a few minutes because I didn't have a good answer prepared, nor a really good demonstration.

Looking back, I think I might have shown him what a text file looks like using a hex editor. Maybe also a simple image format such as PBM or BMP. I searched around on YouTube for a good video, but found pretty much nothing.

If you've been asked this question before, what's your answer? What is a file?

Answer 1

I would approach this pragmatically, beginning with the metaphor that kicked it off. I would tell the students something like this:

Imagine that it's 1925, and you're working at a giant company like General Electric as a secretary. There are files, meaning pieces of paper, for all kinds of things. Personnel files about employees, files of record for payments, files of company policies, board meetings, tax documents, you make it. There are hundreds of rooms holding thousands of file cabinets holding millions of files in hanging folders.

So the metaphor of a file, then, is a document with some information about something. And the metaphor for the folder is as a place to store those files.

We also call these folders "directories", another metaphor. A "directory" is from the same etmological root as direction, and it means "to guide". So, folders can be thought of as places where files sit, or can be thought of as a guide to where files are.

But translating that idea to the very alien mind of a computer involves some tweaks. First there's the idea that folders can contain folders, which can contain more folders still. This is incredibly convenient, and using the same metaphor as "directory", we call the list of folders and subfolders and subfolders that bring us to a particular file as a "path". Get it?

As for the files themselves, there are two perspectives to think about this. Again, the metaphor is there, but it breaks apart a bit in translation:

The first is from the file system, which is concerned with being able to store and retrieve these files. As far as the file system is concerned, a file is a size and a series of locations as to where the various parts of the file are stored. This is because the files don't have to be contiguous inside the computer. It doesn't actually matter if the first half is stored over here in the hard drive and the second half is stored somewhere else, since the file system will retrieve it for us as if it were one document anyway. The file system just has to keep track of everything so that the files can be assembled properly when they are needed.

The second perspective is the perspective of a file itself, which is really just some way to store some data, after all. So far, that's just like a file in our big office. But our files can store so many different kinds of data! We aren't just storing readable text. We can store pictures. We can store sounds. We can store runnable code. All of these require very different internal organizations, so the contents of files are extremely variable.

Many files begin with some sort of metadata. "Hey, I'm a picture, and this is my encoding and my color depth and my size and and and and...". Some files depend on the file system to just remember what kind of files they are. Every file is designed to be read by programs or by the computer itself, and is highly organized to make this possible.

So, a "file" means different things in different contexts, and the only overriding idea is that a file is a way to group data together.

Answer 2

The question is actually quite deep. For instance, I'm sure you've heard the phrase "everything is a file," that is associated with a design of Unix operating system. So, the answer could be puzzling "a file is almost everything in Unix," for example devices can "look like" files to some processes. They use a file as a common interface between many processes. Hence, the file is quite a general notion of a sequence of bytes in Unix.

My simple answer would be that a file is a sequence of bytes with a reference to them, by which you can access these bytes.

Answer 3

I think in this case a short answer is better than a long one, which is harder, but I might give it a shot:

A file is a list of bytes and an identifier [location].

Make sure to explain that there are no physical files and the term is just an abstraction. With my definition you can explain the following:

• If you create a new file with a different identifier but the same bytes, it is a copy of the file.
• If you just change the identifier [location], you say the file moves.
• If you keep the identifier but change the bytes, the file is said to change.

The identifier can be different - e.g. a filename ("C:\Desktop\MyFile.txt") or a URL ("https://www.mydomain.edu/MyFile.txt") - but the content is basically always a list of 0 to many bytes.

You could go into details how files are stored and how HTTP works, but in the end you only need to explain the abstraction to understand what "file" means.

Answer 4

"File" is an abstraction. Even worse, we use it for different abstractions.

Well, suppose I copy a file to this site, and you download it. Would you say it is the same file? What do you mean by same?

Actually, we'll have, more or less, parts of our hard disks (or is it a floppy?) containing bytes which we understand (through the magic of operating systems) as a representation of the same informations.

Answer 5

Was in a conference the other day and someone was showing intercept security... A .exe file started with MZ. Why? Those are the initials of the man who created the first DOS executable file format. Many kinds of files have 'signatures' in the first few bytes.

I used to use a tool called 'strings' that would show any displayable sequences of characters in an otherwise 'binary' file. Helpful sometimes. We have gotten far away from this level of reality in our everyday use of computers, so it is good to show that there is really no mystery, it is all just a heap of ideas people have had over time, piled up in layers. Start at the bottom with characters and follow the clues.

Attack it in many ways, showing the aspects of 'files' that are meaningful to you. Give some of the history. I am sure you can come up with analogies. One issue is that although 'file' makes some sense, 'folder' does not, because we don't ever nest manila folders! Nnnnt! The other term, 'directory', has fallen in to disuse, and really is not any better.

What is a synonym for what we call folder...? There isn't one! It is a brand new concept, like variables. Nothing else in our world is like that. This is why we have to show that analogies are limited and misleading. You have to actually know some things.

Answer 6

Nothing wrong with citing all the "dictionary" definitions found on the Internet.

I'd add that a file tends to be the lowest level of abstraction of a container or boundary around data that the Operating System manages. That is the file's name is accessed through the OS and if you want to know the bits and bytes of data "in" the file you need an Application or program to read/write the file. The OS "promises" to return the data to any Application in the same order in which the creating Application specified but physically the OS may scatter the data to the wind - as long as the OS can return the data properly to some Application.

Answer 7

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.

File content

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 .png.

.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:

1111111111011111

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.

Interesting experiment
Take an existing Word/Excel file, one with an "x" in the file extension (.docx or .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 .docx or .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:

C:\Fruit\apple.txt
C:\People\PeopleILike\Tom.png
C:\Fruit\banana.txt
C:\People\PeopleIHate\Kevin.png

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:

C/
├─ Fruit/
│  ├─ apple.txt
│  ├─ banana.txt
├─ People/
│  ├─ 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.

---

File metadata

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.

Answer 8

A slightly different but insightful take on this :-

On UNIX systems everything is a file. A file of data is a datafile but a directory (folder) is also a file. A device is a file (found in the /dev directory). Programs are executable files and even running program and system states have associated files (found in /run). Network connections are files that can be read and written.

I suppose that explains why its difficult to define what a file is. In a physical sense it is just a list of connected disk or tape or memory sectors containing codes for data values.

Answer 9

I'd actually answer this question from an Intro student from more of the HCI perspective, because they likely have more experience using a computer than understanding how the computer works. @MichelBillaud had a similar notion in suggesting it as an abstraction (although most intro students won't fully appreciate what abstraction means the point of asking what a file is). Relating the abstraction to what they already understand in the physical world helps establish a good foundation.

I'd start by explaining that the first personal computers with graphical interfaces (Xerox Star if they want a historical context) faced the challenge of making it easy for someone who works in an office learn how to work with a computer, which stores information digitally instead of on paper.

In an office, they might have records of a client's information that they'd traditionally write on a piece of paper and store it away in a file cabinet. That file is a record of related information that you can look up by a name. That metaphor works for computers. They store information electronically instead of on paper, but that digital record is organized in one place and can be looked up by the file name.

From there, you can build upon that fundamental to explain different file formats (e.g. plain text vs binary) or how the metaphor extends to other abstractions of digital data represented in ways people can relate to in the physical world (e.g. folders, storage, copying/moving and recycle/trash, to other WIMP metaphors.

Answer 10

A file is a metaphor, representing a mental model that would be familiar to office workers who were the initial users of computing systems.

Different users in a different context require different metaphors as they have different mental models.