Section 8: What Happens When You Create a New Text File (Complete Chain)

The Big Picture: One Right-Click, Ten Layers

You right-click in a folder, choose New → Text Document, and a file called New Text Document.txt appears. It takes a blink. But that blink touches almost everything you have learned in this part of the course: the shell, the Windows programming interface, the kernel, the file system, the driver stack and the disk.

Here is the whole chain from top to bottom. Then we take each stop one at a time.

┌──────────────────────────────────────────────────────────────────┐
│ USER: right-click, New, Text Document                            │
│   You click in an empty folder.                                  │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ EXPLORER (the shell), user mode                                  │
│   Reads the New menu entry for .txt (registry, Chapter 17).      │
│   Picks the name 'New Text Document.txt'.                        │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ WIN32 API: CreateFileW (kernel32 / kernelbase)                   │
│   'Create this file; fail if it already exists.'                 │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ NTDLL.DLL: NtCreateFile, then a system call                      │
│   Switches from user mode into the kernel.                       │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ I/O MANAGER (kernel)                                             │
│   Builds an IRP (I/O Request Packet) 'create file'.              │
│   Passes it down the driver stack (filter drivers first).        │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ NTFS DRIVER (ntfs.sys)                                           │
│   1. Checks the parent folder's ACL (permission).                │
│   2. Allocates a free MFT record for the new file.               │
│   3. Writes its attributes (name, times, empty data).            │
│   4. Adds a name entry to the parent's index ($I30).             │
│   5. Writes the change to $LogFile (the journal).                │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ VOLUME MANAGER / PARTITION MANAGER                               │
│   Turns a position in the volume into a position on the disk.    │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ DISK CLASS DRIVER (disk.sys)                                     │
│   Turns the request into a disk read/write command.              │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ STORAGE PORT + MINIPORT DRIVER (storport, stornvme, storahci)    │
│   Talks to the controller hardware (drivers: Chapter 13).        │
└──────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│ DEVICE: SSD or hard drive (Chapter 18)                           │
│   The controller writes it to flash or to the magnetic platter.  │
└──────────────────────────────────────────────────────────────────┘

Read it as a relay race. Each layer takes the request, does its own job, and hands it to the layer below. Nothing at the top knows how the layer at the bottom works. That separation is what lets the same Notepad work on an SSD, a hard drive or a USB stick.

8.1 Explorer → CreateFile Win32 API Call

What it is: The folder window you see is File Explorer, also called the shell (the part of Windows that shows you folders and icons). When you click New → Text Document, Explorer needs to know what "Text Document" means.

How Explorer knows: Windows keeps a list of "New" menu entries in the registry (Chapter 17). The .txt file type has a small ShellNew entry there that says "to make one, create an empty file". Explorer picks the default name New Text Document.txt (adding a number if one already exists) and then puts the name into rename mode, so you can type a new one right away.

The API call. Explorer does not touch the disk. It asks Windows to do so, through a Win32 API (a documented function that programs call). The function is CreateFileW. Despite its name, it both creates and opens files. Explorer passes the full path and a flag meaning "create it new; fail if it already exists".

Inside the call: CreateFileW lives in system libraries (kernel32.dll and kernelbase.dll). It tidies the path, then calls a lower-level function in ntdll.dll named NtCreateFile. That function runs a special CPU instruction (a system call) which switches the processor from user mode (where ordinary programs run) into kernel mode (where Windows itself runs with full power). Chapter 3 touched on this boundary when it explained why programs cannot touch memory freely.

8.2 I/O Manager Creates IRP

What it is: Inside the kernel, the I/O Manager is the dispatcher for all input and output requests: files, disks, network, keyboards. It turns your request into an IRP (I/O Request Packet): a small data structure that says "what is wanted" (here: create a file), "where" (this path) and "who is asking".

Why a packet? The IRP can be handed from driver to driver down a stack. Each driver looks at it, does its part, and passes it on (or completes it). Drivers are covered in Chapter 13.

Who sees it first? Before it reaches the file system, the IRP may pass through filter drivers: for example, your antivirus (such as Windows Security) can look at the new file request, and cloud-sync tools can watch it. Think of security guards at the building entrance.

Name resolving. The I/O Manager also works out which volume the path belongs to (C: is a name pointing to a device) and sends the IRP to that volume's file system driver. For an NTFS volume, that is ntfs.sys.

8.3 NTFS Driver Allocates MFT Entry

What it is: ntfs.sys is the NTFS driver. It now holds a request: "create New Text Document.txt in this folder". This is the heart of the chain. It does these jobs, in this spirit:

1. Find the parent folder. It walks the path from the root, using each folder's sorted index (Section 3.2) until it reaches the target folder.
2. Check permission. It checks that you may create files there, by testing the folder's ACL against your access token (Section 5.2). If not, you see "You need permission to perform this action".
3. Check the name. It looks in the folder's index to make sure the name does not exist yet.
4. Allocate an MFT record. It finds a free 1 KB record in the Master File Table (Section 4.1). The MFT's own free-record map says which rows are unused.
5. Fill in the record. It writes the attributes: $STANDARD_INFORMATION (times, flags), $FILE_NAME (the name and its parent), the security information (inherited from the parent folder, Section 5.4), and an empty $DATA attribute.
6. Add a directory entry. It adds a new name entry (name plus file reference number, Section 4.2) into the parent folder's $I30 index, keeping the list sorted.

 BEFORE                            AFTER

 Parent folder index ($I30)        Parent folder index ($I30)
   Notes.docx   -> record 90         Notes.docx   -> record 90
   Photo.jpg    -> record 95         New Text Document.txt -> record 120
                                     Photo.jpg    -> record 95

 MFT:  record 120 = free           MFT:  record 120 = our new file
                                         (name, times, security,
                                          empty data, 0 bytes)

8.4 Free Clusters Located via Bitmap ($Bitmap)

What it is: Here is a surprise worth knowing. A brand-new empty text file uses no clusters at all. Its $DATA attribute is resident and holds 0 bytes (Section 4.1), so there is nothing to place on the disk yet. The cluster hunt only begins when data arrives.

When clusters are needed: The moment a file grows too big to fit inside its 1 KB MFT record, NTFS consults the $Bitmap (Section 4.3): one bit per cluster, 0 for free and 1 for used. It scans for a free run of clusters, flips those bits to 1, and writes an extent (start and length) into the file's record. That is also when the file stops being resident and becomes non-resident.

 File is tiny (say 20 bytes)       File grows to 6,000 bytes

 MFT record holds the 20 bytes     NTFS asks $Bitmap: "2 free clusters?"
 No clusters used                  Bitmap: "clusters 7,431 and 7,432"
                                   MFT record now holds the extent
                                   (start 7,431, length 2)

So for the "create an empty file" step the bitmap is not used at all; it is the saving step (Section 8.8) that needs it once the text is bigger than a few hundred bytes.

8.5 Journal Entry Written ($LogFile)

What it is: Creating a file means several linked changes (a new MFT record, a new folder entry, a possible change to the bitmap). Remember Section 4.4: NTFS records its plan in the $LogFile journal before the real structures are written. That is why NTFS is called a journaling file system.

The order:

1. NTFS writes log records that describe "create record 120" and "add this entry to the folder".
2. NTFS makes the change in the cached copies of the MFT and the folder index in memory.
3. Those changed blocks are written to the disk a little later (see the next point).
4. The log is trimmed once the changes are safely on the disk.

If the power fails between steps, NTFS reads the log at the next start and either finishes or undoes the half-done operation. Either way your folder structure stays valid.

Cache Manager and the lazy writer. Windows does not write every small change to the disk instantly. The Cache Manager keeps recently used file data and metadata in RAM (Chapter 3 explained caching). A background worker called the lazy writer writes changed blocks to the disk in batches, roughly every second. This makes Windows far faster. The journal is the safety net that makes the delay acceptable.

8.6 Storage Driver Sends Write Command

What it is: When NTFS finally needs data to go to the disk (the log records, then the changed metadata), it creates new IRPs for writing and sends them further down the stack:

The miniport talks to the real hardware over the bus you met in Chapter 4: for an NVMe SSD that is PCIe; for a SATA drive it is the SATA link. The controller can then move the data directly to and from RAM by DMA without the CPU copying every byte.

8.7 Physical Write to SSD/HDD

What it is: The last stop is the device itself (Chapter 18).

When the device reports "done", the driver stack completes the IRP upwards: the miniport tells storport, which tells the class driver and so on, until NTFS knows its write is on the disk. Finally, back at the top, CreateFileW returns a handle (a small ticket number meaning "this open file") to Explorer, and the file appears in your window.

8.8 Later: You Type and Save

What it is: The empty file now exists. You double-click it, Notepad opens, you type hello and press Ctrl + S. The chain runs again, this time for data.

Notepad: WriteFile("hello")
   │
   ▼
I/O Manager ──► NTFS driver
   │               │
   │               ├─ Is it tiny (a few hundred bytes or less)?
   │               │      YES: keep the data resident, inside the MFT record
   │               │      NO:  find free clusters via $Bitmap, record extents
   │               │
   │               ├─ Update size and Modified time in the MFT record
   │               └─ Log the change in $LogFile
   ▼
Cache Manager keeps the changed data in RAM
   │
   ▼   (about a second later, the lazy writer)
Volume / disk / port drivers ──► the device

Two details:

• Because "hello" is only 5 bytes, NTFS will almost certainly keep it resident. This is the "tiny file stored inside the MFT record" trick from Section 4.1, so no cluster is used.
• A program that must be sure its data is on the disk (for example a database) asks Windows to flush the cache. A normal Save relies on the lazy writer. This is why you should always use Safely Remove Hardware before pulling out a USB drive: the data may still be waiting in the cache.

8.9 The Whole Chain at a Glance

Where the earlier chapters fit in: Chapter 18 is the device at the bottom; Chapter 3 gave us the cache and the user/kernel split; Chapter 13 covered the drivers in the middle; Chapter 17 is the registry that told Explorer how to make a text file.

Summary