Comment by p_ing
18 days ago
NTFS will perform directory B+-tree lookups (this is where it walks the path) until it finds the requested file. The Cache Manager caches these B+-trees.
From there, it hits the MFT, finds the specific record for the file, loads the MFT record, and ultimately returns the FILE_OBJECT to the I/O Manager and it bubbles up the chain back to (presumably) Win32. The MFT is just a linear array of records, which include file and directories (directory records are just a record with directory = true, essentially).
Obviously simplified. Windows Internals will be your friend, if you want to know more.
Thanks for the explanation! Linux, meanwhile, will[1] in the normal case walk a sequence[2] of hash tables (representing incomplete but up-to-date views of directories) before hitting the filesystem’s vtable or the block I/O layer at all, and on the fast path[3] taking no locks other than the RCU read lock.
[1] https://www.kernel.org/doc/html/latest/filesystems/path-look...
[2] I was under the impression that it could look up an entire path at once when I wrote my grandparent comment; it seems I was wrong, which on reflection makes sense given you can move directories.
[3] https://www.kernel.org/doc/html/latest/filesystems/path-look...
Heh, first I've heard of Windows Internals. New friends for The Linux Programming Interface!
Yes, won't be that quite in depth given no source code, but you can easily look up the NT4 source code on GitHub if you want to dive that deep. I would assume much of that code should still be relevant today.
Also worth tracking down a copy of the NT OS/2 Design Workbook on the web (another leak).
And Inside the Windows NT File System by Helen Custer is a very short book but describes the very early state of NTFS capabilities/functions.