You double-click a document.
An application opens.
You save your work.
A file appears in a folder.
You close the application.
Later, you open the same file again and continue where you stopped.
To a user, this feels simple.
To Windows, it involves several different systems cooperating:
storage → file system → path → permissions → application → process → memory
Understanding that chain changes the way you think about files.
A file is not simply “something inside a folder.”
A Windows file is an object represented by a file system, identified through a path, accessed through operating-system interfaces, and ultimately handled by a running process.
Once you understand that, many everyday Windows problems become easier to investigate.
The file you see is not the storage itself
Suppose you create:
report.docx
You might think:
“The document is stored in that file.”
At a user level, that is a perfectly reasonable description.
Technically, however, the operating system is dealing with information about the file as well as its contents.
The storage device contains physical or flash-based storage.
A file system organizes that storage.
The file system maintains structures that allow Windows to locate files and directories and maintain information about them.
Windows provides applications with interfaces for accessing those files.
The application interprets the contents.
So the mental model is:
STORAGE DEVICE
↓
FILE SYSTEM
↓
FILE / DIRECTORY STRUCTURE
↓
WINDOWS FILE ACCESS
↓
APPLICATION
↓
PROCESS
The file you see in File Explorer is therefore the visible representation of a much deeper system.
A disk needs organization
Imagine buying an enormous warehouse and placing millions of objects inside it without labels, shelves, addresses, or an inventory system.
The objects may physically exist.
Finding one would be extremely difficult.
A computer storage device faces a similar problem.
It contains a huge amount of information, but software needs a way to organize and locate that information.
A file system provides that organization.
On Windows, common file systems include:
- NTFS;
- exFAT;
- FAT32.
They are not simply different names for the same thing.
They provide different capabilities and are designed for different environments.
For everyday Windows installations, NTFS is particularly important because it supports capabilities required by modern Windows systems, including permissions and other file-system features.
The important concept is broader than any one file system:
The operating system needs a structured method for turning storage into named, addressable objects that applications can use.
A folder is a logical structure
Consider:
C:\Users\Alex\Documents\Report.docx
A beginner may see this as a long label.
Windows sees a hierarchy.
At the top is:
C:\
Then:
Users
Then:
Alex
Then:
Documents
Then:
Report.docx
Each directory provides another level of organization.
Conceptually:
C:\
└── Users
└── Alex
└── Documents
└── Report.docx
The full location is the path.
The path tells Windows where the object is located within the namespace exposed by the file system.
A path is an address
You already understand addresses in the physical world.
A delivery address tells a person where something should go.
A network address helps communication systems identify a destination.
A file path performs a related function within the file namespace.
For example:
C:\Projects\Website\index.html
tells Windows:
- use the
C:volume; - enter the
Projectsdirectory; - then
Website; - then locate
index.html.
This is why a file can be moved without changing its contents.
Its location in the namespace changes.
The file's data and its path are related but conceptually different things.
Extensions tell you something about a file
You have probably encountered:
.jpg
.png
.pdf
.docx
.xlsx
.exe
.txt
.html
.js
The extension is commonly used to indicate the type of content or the application associated with a file.
For example:
report.pdf
suggests that the file contains PDF-formatted data.
script.js
suggests JavaScript source code.
program.exe
is associated with an executable Windows program.
But the extension itself is not the entire definition of what the file contains.
Changing:
photo.jpg
to:
photo.pdf
does not magically convert a JPEG image into a PDF document.
You have changed the name.
You have not necessarily changed the underlying data format.
This distinction becomes important when troubleshooting files that appear to be the wrong type.
Opening a file is really a request to another program
Suppose you double-click:
Report.docx
The document itself does not suddenly become an application.
Windows needs to determine what should handle it.
The system can associate particular file types with applications.
For example:
.docx → document application
.jpg → image application
.mp4 → media application
.html → browser or other associated application
The exact application depends on the system configuration.
Once Windows determines what should open the file, it launches or communicates with the appropriate application.
That application then reads the file's contents.
This gives us a more accurate sequence:
DOUBLE-CLICK FILE
↓
WINDOWS IDENTIFIES THE REQUEST
↓
FILE ASSOCIATION
↓
APPLICATION IS FOUND
↓
APPLICATION PROCESS RUNS
↓
APPLICATION OPENS FILE
The file did not “run.”
The application did.
This is where processes become important
In the previous Windows chapters, we looked at processes as running instances of programs.
Now connect that concept to files.
Suppose you open a photo editor.
Windows creates or activates a process associated with that application.
The process receives access to the image file.
The application reads the file.
The image data is loaded into memory.
The processor executes the application's instructions.
The application then displays the image.
The file remains on storage.
The running application works with a representation of its contents in memory.
This distinction is fundamental:
storage is not memory, and a file is not a running process.
Why an application needs memory to work with a file
Imagine a 50 MB image file.
The CPU does not normally execute the JPEG file as though it were program instructions.
The application reads the file's data.
Windows helps provide access to that data.
The application decodes it.
The resulting information may occupy considerably more memory than the compressed file itself.
The application can then manipulate the image.
For a document editor, something similar happens.
A document file on disk contains encoded information.
The application reads it and constructs an internal representation in memory.
You edit that representation.
When you save, the application writes an updated representation back to storage.
So the workflow becomes:
FILE ON STORAGE
→ read
→ DATA IN MEMORY
→ modify
→ save
→ UPDATED FILE ON STORAGE
This is why saving is not the same thing as merely changing what you see on screen.
What happens when you press Save?
Imagine editing:
Report.docx
You type a new paragraph.
What changed first?
The application state in memory.
The application now has information representing the modified document.
When you select Save, the application asks Windows to write the updated information to the appropriate file.
Windows and the file system then handle the operation.
The exact internal sequence can be more complicated than this simplified model, involving buffering, caching, metadata updates, temporary files, and other mechanisms.
But the important mental model is:
EDITING changes application state.
SAVING makes persistent storage reflect that state.
This distinction explains why an unsaved document can disappear when an application crashes.
The latest changes may have existed only in memory.
Why Windows sometimes says a file is “in use”
Suppose an application opens a file.
The application may maintain an open handle to that file.
Windows tracks access to objects through operating-system mechanisms.
Depending on the application and the way the file was opened, another process may be prevented from performing certain operations on it.
This is why you might encounter messages such as:
The file is being used by another program.
The problem is not necessarily that Windows has forgotten where the file is.
The file may be perfectly healthy.
Another process may currently have it open in a way that conflicts with what you are trying to do.
This is one of the places where the concepts of files and processes meet.
Permissions answer a different question
Now imagine you find the correct file but Windows refuses to let you modify it.
That introduces another system:
permissions.
A file can exist.
You can know its path.
An application can know how to open files.
And yet Windows may still prevent a particular user or process from performing a requested operation.
Why?
Because the operating system must control access to resources.
Permissions can determine whether a user or security principal is allowed to perform actions such as:
- reading;
- writing;
- modifying;
- executing;
- deleting.
The exact security model is more sophisticated than this simplified list, but the principle is important.
Finding a file does not automatically give you permission to change it.
Identity and permission are connected
When Windows needs to decide whether an operation is allowed, it needs to know who or what is requesting the operation.
This brings us back to identity.
A Windows system can have:
- user accounts;
- groups;
- security identifiers;
- processes;
- security tokens;
- access control information.
The operating system can use this information when evaluating access.
Conceptually:
WHO IS REQUESTING?
WHAT OBJECT IS BEING REQUESTED?
WHAT OPERATION IS BEING REQUESTED?
=
SHOULD ACCESS BE ALLOWED?
That same pattern appears throughout computing security.
A file can have more than one layer of information
A file has its contents.
But Windows may also maintain metadata associated with it.
Depending on the file system and object, this can include information such as:
- name;
- timestamps;
- size;
- attributes;
- permissions;
- ownership-related information;
- location within the file-system namespace.
This explains why two files with similar visible content can behave differently.
One might be:
- read-only;
- hidden;
- protected by permissions;
- stored on a different volume;
- accessed by another process.
The visible document is only part of the system.
Drives are not the same thing as physical disks
Windows commonly exposes storage using drive letters:
C:
D:
E:
It is tempting to think:
C: = one physical hard drive.
That is not necessarily true.
A physical storage device can contain multiple partitions or volumes.
Windows can expose storage through logical volumes.
A system can also have additional storage configurations that make the relationship between physical hardware and drive letters more complicated.
Therefore:
drive letter ≠ necessarily physical disk
The drive letter is part of the logical namespace through which Windows exposes storage.
Why C: is usually special
On a typical Windows installation, the system volume is commonly assigned:
C:
This is where Windows and many installed applications reside.
But the letter itself is not a universal law of computing.
Drive letters are assignments within Windows.
A removable device might receive another letter.
A different storage configuration may change available letters.
The deeper concept is the volume and its namespace, not the letter itself.
What happens when you unplug a USB drive?
Suppose you connect a USB flash drive.
Windows detects the device.
It communicates with the storage hardware.
The storage device exposes its data through a file system.
Windows recognizes the volume.
A drive letter may be assigned.
File Explorer displays the contents.
You open a file.
An application reads it.
Now imagine removing the drive while the file is still being accessed.
The application may suddenly lose access to the underlying storage.
This illustrates another important principle:
applications depend on resources remaining available.
The same idea applies to:
- network drives;
- cloud-synchronized folders;
- external storage;
- databases;
- APIs;
- printers;
- other system resources.
Why a shortcut is not the file
Windows shortcuts are another useful example of the difference between an object and its location.
Suppose your desktop contains a shortcut to:
C:\Projects\Website\index.html
The shortcut is not necessarily a second copy of index.html.
It provides a convenient reference to the target.
This is similar to creating a sign pointing toward a building.
Destroying the sign does not necessarily destroy the building.
Likewise, deleting a shortcut does not normally delete the target file.
This distinction becomes useful when understanding:
- shortcuts;
- symbolic links;
- file references;
- application launchers;
- paths.
The command line exposes the file system differently
File Explorer gives you a visual interface.
The command line gives you a textual interface to many of the same underlying concepts.
For example:
dir
can display directory contents.
And:
cd Documents
changes the command-line working directory.
You can think of this as interacting with the same logical namespace through a different interface.
That is an important lesson:
the graphical interface is not the operating system itself.
File Explorer is an application.
The Windows operating system provides deeper services underneath it.
Other programs can interact with those services through different interfaces.
PowerShell takes this even further
Windows also provides PowerShell, which treats many system resources as objects that can be inspected and manipulated through commands.
This is more than an alternative way to open folders.
It allows administrators and developers to automate system operations.
For example, instead of manually inspecting hundreds of files, a script can:
- search directories;
- examine properties;
- filter files;
- rename objects;
- copy data;
- collect information;
- automate repetitive operations.
Now the file system becomes programmable.
This is where ordinary computer use begins to connect with systems administration and software engineering.
Files become inputs to larger systems
Consider a website project.
You might have:
Website/
├── index.html
├── style.css
├── script.js
└── images/
The files are not independent.
The HTML references the CSS.
The HTML may reference JavaScript.
The HTML or CSS may reference images.
A browser loads the files and constructs an application-like experience from them.
This demonstrates another important concept:
files can be components of a larger software system.
The file system provides the organization.
The operating system provides access.
The development tools manipulate the files.
The browser or runtime interprets them.
The result becomes a running digital system.
The file system therefore sits between hardware and software
We can now place everything into one chain:
PHYSICAL STORAGE
↓
VOLUME / FILE SYSTEM
↓
DIRECTORIES + FILES
↓
PATHS + METADATA + PERMISSIONS
↓
WINDOWS FILE ACCESS
↓
APPLICATION
↓
PROCESS
↓
MEMORY
↓
CPU
This is a powerful model because it explains why a problem at one level can appear at another.
A file might seem missing because:
- the path is wrong;
- the drive is unavailable;
- the volume is not mounted as expected;
- permissions prevent access;
- the application is looking somewhere else;
- another process has the file open;
- the file has been moved;
- the file system has a problem.
Without the underlying model, these problems look random.
With the model, they become investigation problems.
Start troubleshooting from the object, not the symptom
Suppose an application says:
“File not found.”
Do not immediately conclude that the file has been deleted.
Ask:
What exact path is the application using?
Then:
Does that path exist?
Then:
Is the correct drive or volume available?
Then:
Can I access the file manually?
Then:
Does the application have permission to access it?
Then:
Is another process interfering with the operation?
Then:
Is the application expecting a different file format or location?
This is the Windows troubleshooting mindset:
observe → identify the object → trace the dependency → test the assumption → isolate the layer causing the failure.
The deeper lesson about Windows
Windows is often experienced as a desktop.
But the desktop is only one layer of the operating system.
Behind the desktop are systems for:
- processes;
- memory;
- storage;
- files;
- security;
- networking;
- services;
- devices;
- scheduling;
- configuration;
- application execution.
The previous chapters showed how Windows manages running work.
This chapter connects that running work to persistent information.
A process needs memory.
An application needs files.
Files depend on storage.
Storage is organized by file systems.
Access is controlled by permissions.
Paths connect applications to objects.
And Windows coordinates the entire chain.
That is what an operating system does.
It creates a usable environment in which software can interact with hardware and with other software without every application having to understand the physical machinery underneath.
The mental model to keep
The next time you double-click a document, don't see only:
icon → document
See:
USER ACTION
↓
FILE PATH
↓
FILE SYSTEM
↓
STORAGE
↓
WINDOWS ACCESS CONTROL
↓
APPLICATION
↓
PROCESS
↓
MEMORY
↓
CPU
↓
VISIBLE RESULT
And when you save:
APPLICATION STATE
↓
FILE WRITE
↓
FILE SYSTEM
↓
STORAGE
↓
PERSISTENT DATA
That chain explains why files can be opened, modified, locked, protected, moved, copied, synchronized, and lost.
It also prepares us for a deeper Windows question.
If files are persistent objects and processes are running objects, how does Windows connect all these resources together while keeping thousands of applications, users, devices, and system components from interfering with one another?
The answer leads into one of the most important ideas in modern operating systems:
handles, security boundaries, services, system calls, and the Windows object model.
Image: Microsoft Learn
.png)
No comments:
Post a Comment