For most of the history of personal computing, files and directories were not something hidden behind an application. They were part of how you understood the machine.
A document had a name. It lived somewhere. That place was inside a directory, which might itself be inside another directory. Applications opened files, saved files, copied files, and sometimes created their own folders, but the underlying structure was still visible.
That model has become less obvious in modern software. Many applications now manage their own content internally, synchronize it through cloud services, and present users with notes, projects, photos, conversations, or workspaces instead of files and folders.
That can be convenient, but the file system still matters because it gives information a structure that exists independently of the application currently using it.
Files Are a Simple Contract
A file is one of the most basic abstractions in computing.
The operating system gives a collection of data a name and a location, along with metadata such as ownership, permissions, timestamps, and size. Programs can read or modify that data without necessarily needing to understand how the storage device works underneath.
That abstraction has been extraordinarily successful because it creates a simple contract between software and the operating system.
A text editor does not need to know whether a file lives on a hard disk, SSD, network share, or removable drive. It asks the operating system to open the file. The file system handles the details.
The same abstraction also helps users. We can think in terms of documents and directories instead of disk sectors and storage blocks.
That is a good abstraction because it hides complexity without hiding the existence of the information itself.
Directories Give Information a Place
Directory structures do more than keep files from piling up in one enormous list.
They create relationships.
A folder called Taxes inside a folder called 2026 conveys something about the files inside it before any application opens them. A directory tree can represent projects, years, customers, subjects, machines, photographs, source code, research, or almost anything else.
The structure is visible and usually understandable without specialized software.
That matters because organization survives changes in applications.
If I have a directory containing Markdown files, images, PDFs, and spreadsheets, I can replace the applications that open those files without necessarily changing the way the information itself is organized. The directory tree belongs to the user rather than to one program.
That separation is easy to underestimate.
The File System Is Application-Agnostic
One of the strongest arguments for ordinary files is that many different programs can work with the same data.
A photograph stored as a JPEG does not belong to the photo viewer. A text file does not belong to the editor that created it. A PDF does not stop existing because I uninstall the program I normally use to read it.
That sounds obvious, but it is not how all modern software behaves.
Some applications treat information primarily as objects inside their own system. A note may exist as a record in a database. A project may consist of data spread across several internal files. A collection of photographs may be represented through a library managed by one application rather than through directories the user normally sees.
There are good technical reasons for doing this. Databases can handle metadata, relationships, indexing, synchronization, versioning, and search much more efficiently than a loose collection of ordinary files in many situations.
The tradeoff is that the application becomes more important to the data.
Application-Managed Content Solves Real Problems
It would be easy to make this into a complaint about modern software hiding everything, but that would miss why application-managed content became common.
A photo-management program may need to store ratings, faces, edits, albums, tags, locations, and multiple versions of the same image. A note-taking application may support links between notes, embedded files, synchronization, full-text search, and collaboration. A music application may need playlists, album metadata, artwork, and listening history.
Trying to represent all of that cleanly as a visible hierarchy of ordinary folders can become awkward.
The database approach can be much better for the application.
It also makes the user experience simpler. Someone taking a photograph on a phone does not want to choose a directory path and filename first. The useful abstraction is usually “my photos,” not /storage/DCIM/Camera/IMG_20261030_114522.jpg.
That is a reasonable design choice.
The problem comes when the abstraction becomes the only usable way to reach the information.
There Is a Difference Between Hiding Complexity and Hiding Data
Good software hides details the user should not have to manage manually.
I do not need to know the physical block address where a document lives on an SSD. I do not want to manually maintain a database index every time I edit a note. Those are implementation details.
But knowing where my data is and whether I can access it independently is not necessarily an implementation detail.
There is an important difference between an application saying, “You do not need to care how I organize this internally,” and saying, “You cannot meaningfully access this without me.”
The first is abstraction. The second is dependency.
An application can manage content internally while still providing reliable export, standard formats, backups, or direct access to the underlying files. When those escape routes exist, the abstraction is much less concerning.
When they do not, the user’s information and the application become tightly coupled.
File Organization Is a Form of Knowledge
A directory tree also represents knowledge that may exist nowhere else.
Suppose I maintain research material in a hierarchy organized by project, subject, and date. The folder structure itself tells me how I have decided those materials relate to one another.
That organization can be crude, and it may not scale perfectly, but it is durable.
I do not need an application to interpret the relationship. If the structure is Research > Networking > ARPANET > Primary Sources, the meaning is apparent from the path.
Application-managed systems often represent relationships more flexibly through tags, links, metadata, saved searches, and databases. Those approaches can be much more powerful than a single hierarchy.
They can also be less portable.
If the software disappears, the question becomes whether those relationships can be exported in a useful form or whether they existed only inside the application.
Hierarchies Have Real Limitations
The file system should not be treated as the perfect organizational model.
A file usually has one primary location in a directory hierarchy. Real information does not always fit so neatly.
A document about both Linux and networking has to live somewhere, even if both categories make equal sense. You can solve that with symbolic links, shortcuts, tags, or duplicate files, but those are additional mechanisms layered on top.
Large directory trees can also become difficult to navigate. People create folders called Misc, Old, New, Archive, Stuff, or the particularly dangerous Final followed by Final2 and Final-Really.
Search often works better than careful hierarchical filing when there are thousands of items.
Modern applications did not abandon visible file organization simply because designers wanted to take control away from users. They were also trying to solve genuine weaknesses in the folder model.
Search and Hierarchy Work Better Together
The mistake is assuming that search makes structure unnecessary.
Search is excellent when I remember enough about something to describe it. A directory is useful when I know roughly where it belongs or when I want to browse related material.
Those are complementary approaches.
A well-organized file system combined with good search is generally more useful than either one alone. The directory structure provides context, while search provides speed.
The same principle applies inside applications. Tags and search can make a large collection easier to navigate, but some visible organization still helps users understand what the collection contains and how pieces relate to one another.
Pure search can become surprisingly fragile when you do not remember the right keywords.
Files Make Backups Understandable
One of the practical strengths of ordinary files is that backup is conceptually simple.
If a directory contains my work, I can copy that directory somewhere else. Backup software can operate on it. Synchronization tools can replicate it. Version-control systems can track appropriate files. I can inspect the copy afterward and verify that the files are there.
Application-managed content may be more complicated.
The application’s data might live in a database, several support directories, cloud storage, or some combination of those. Copying one visible folder may not be enough to create a usable backup.
This does not mean databases are bad for backup. Proper database systems often have excellent backup and recovery mechanisms.
The difference is that the backup procedure becomes application-specific.
Ordinary files are easier to reason about because the unit being backed up is also the unit the user recognizes.
Files Are Easy to Move Between Systems
Portability is another reason the file system continues to matter.
If I have a directory of ordinary documents, I can move it from Windows to Linux, copy it to a NAS, put it on an external drive, transfer it over SSH, synchronize it to another computer, or store it on a server.
Some filename restrictions, permissions, metadata, and file-system differences can complicate this, but the basic operation remains straightforward.
Application-managed content is often less obvious.
Moving from one application to another may require an export-and-import process. Some metadata may be lost. Attachments may come out in strange directory structures. Links between items may stop working. In the worst cases, the export exists mainly to satisfy the claim that an export exists.
A directory full of standard files is much less ambitious, but it is usually easier to take somewhere else.
The File System Is Also an Automation Interface
Files and directories are not only useful to humans.
They are one of the most common interfaces between programs and automation tools.
Scripts can watch directories, rename files, process images, search documents, create archives, compare versions, synchronize data, or move completed work from one location to another.
This is one reason visible file systems remain so important in programming, system administration, research, publishing, and other technical work.
A file has an address that can be passed to another program.
Application-managed content may offer APIs or automation interfaces, and those can be far more sophisticated. The problem is that they are specific to the application.
A file path is a comparatively universal interface.
Cloud Storage Complicated the Meaning of “Local”
Cloud synchronization has made file systems more convenient and more confusing at the same time.
Services such as OneDrive, iCloud Drive, Dropbox, and Google Drive can present remote content through what looks like an ordinary directory. This is useful because applications can work with cloud-hosted data through familiar file operations.
The difficulty appears when the file system shows an object that is not fully present on the local machine.
A file may be represented by a placeholder and downloaded only when needed. That saves local storage, but it complicates an assumption that used to be simple: if I can see the file in my directory, I have the file.
Now the questions may include whether the item is local, cached, synchronized, available offline, or only represented by metadata.
The file system is still visible, but part of its meaning has become abstract.
Mobile Computing Hid the File System Further
Phones and tablets pushed this much farther.
Mobile operating systems generally emphasize applications and content rather than user-managed directory trees. A user thinks in terms of photos, messages, documents, recordings, and downloads, not file-system paths.
For most users, that is an improvement.
A phone should not require knowledge of directory structures just to attach a photograph to a message. Application sandboxing also improves security by restricting how freely one application can manipulate another application’s data.
Still, the design changes expectations.
Someone who has primarily used application-centered devices may understand information as belonging to applications rather than existing separately as files.
That becomes noticeable when they move to a conventional desktop environment or need to perform a task that requires knowing where a file actually went.
The user is not failing to understand the computer. The interface has deliberately avoided teaching that model.
The File System Gives You an Exit
For me, one of the strongest arguments for file-based workflows is not convenience. It is the ability to leave.
If my notes are ordinary text or Markdown files, I can change editors.
If my photographs are ordinary image files organized in directories, I can change photo viewers.
If my documents are stored in widely supported formats, I can change office suites.
The transition may not be painless, and some application-specific metadata may still be lost, but the core information remains available independently of the tool.
That is a valuable property in software because applications change much faster than personal information does.
I may keep a document for thirty years. I probably will not use the same application for thirty years.
Application Independence Has Limits
There is a temptation to take this argument too far and insist that every application should store everything as obvious files in user-visible directories.
That would not always produce better software.
Some applications fundamentally need databases. Others depend on complex relationships, transactions, indexing, or synchronization state that cannot be represented cleanly as a few files in a folder.
The more useful standard is whether the application provides a reasonable path out.
Can the user export the important data? Are the formats documented or widely supported? Can the content be backed up independently? Does the export preserve useful structure? Can another program make sense of it?
An application can use sophisticated internal storage without trapping the user’s information.
The problem is not abstraction. It is abstraction without escape routes.
Visible Structure Still Has Value
The file system has survived because it provides something both simple and powerful: a visible namespace for information.
Names have meaning. Locations have meaning. Directories establish context. Permissions control access. Files can be copied, moved, backed up, searched, processed, and opened by different programs.
None of this prevents higher-level software from building better interfaces on top.
That is how good abstractions should work. The application can make routine tasks easier while the underlying files remain available when the user needs more control.
When the lower layer disappears completely, the user becomes more dependent on whatever sits above it.
Files Are Boring Infrastructure
The file system is easy to overlook because it is old and mostly works.
Modern applications offer far richer ways to organize information than directories alone. Databases, tags, search, links, cloud synchronization, collaboration systems, and metadata can all improve on the basic hierarchy.
But the humble file still has an unusual advantage: it is understood by almost everything.
A file can outlive the application that created it. A directory structure can move to another machine. A collection of documents can be backed up without asking permission from the software that normally opens them.
That kind of independence is not exciting, but it is useful.
The best systems often combine both approaches. Let the application provide search, metadata, synchronization, and a better interface, but keep the user’s information in formats and structures that do not make the application indispensable.
The file system still matters because it gives us a layer of organization beneath the applications.
When that layer remains accessible, the data is still ours in a very practical sense.