# Directory (computing)
A directory (also called a folder) is a file system container that holds named references to files and to other directories, allowing a computer's storage to be organized as a hierarchy called a directory tree. Each entry in a directory associates a name with the location of the file's metadata, and the position of a file in the tree is expressed as its path.
| Key fact | Detail |
|---|---|
| Core structure | A directory is a special file maintained by the file system that contains a list of entries; the hierarchy of directories is the directory tree[1](https://www.landley.net/history/mirror/unix/multics/fjcc4.html) • [2](https://learn.microsoft.com/en-us/windows/win32/fileio/about-directory-management) |
| Classic entry format | Early UNIX directories held 16-byte entries consisting of a 14-byte name and an i-number, with the root at a known i-number (2)[3](https://www.cis.upenn.edu/~bcpierce/courses/dd/papers/thompson78unix.pdf) |
| Modern indexing | ext3/ext4 organize large directories with a hashed btree (htree) keyed on a 31-bit hash of the entry name[4](https://kernel.org/doc/html/latest/filesystems/ext4/directory.html) |
| Metadata cost | Nearly 50% of file operations relate to file system metadata in a network file system workload study[5](https://doi.org/10.1145/3620673) |
| Hard links | NTFS allows more than one entry for a single file in a directory entry table; Microsoft documents no limit on the number of hard links per file[2](https://learn.microsoft.com/en-us/windows/win32/fileio/about-directory-management) |
| Human usage | Files are retrieved from a mean depth of 2.86 folders, with a mean of 11.82 files per folder, in a study of 296 participants[6](https://onlinelibrary.wiley.com/doi/abs/10.1002/asi.21415) |
| Flat alternatives | Amazon S3 has no hierarchy of subbuckets or subfolders; folders are inferred from key-name prefixes and the `/` delimiter[7](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html) |
## Structure and entries
A directory that contains other directories is their parent, and each contained directory is a child; the whole structure is the directory tree[2](https://learn.microsoft.com/en-us/windows/win32/fileio/about-directory-management). In the classic UNIX design, the directory is just another type of file, accessed exactly like an ordinary file, whose contents are name-to-i-number pairs[3](https://www.cis.upenn.edu/~bcpierce/courses/dd/papers/thompson78unix.pdf). The i-number locates the inode, the data structure holding a file's metadata, so resolving a path means reading each directory along the way to obtain the next i-number[3](https://www.cis.upenn.edu/~bcpierce/courses/dd/papers/thompson78unix.pdf).
**Entries and links.** A single file can appear under several names. On NTFS, the link between a directory and the files it contains is implemented as a directory entry table; creating an additional entry for a file makes a hard link, and Microsoft documents no limit on the number of hard links per file[2](https://learn.microsoft.com/en-us/windows/win32/fileio/about-directory-management). Directories can also contain junctions and reparse points[2](https://learn.microsoft.com/en-us/windows/win32/fileio/about-directory-management).
## Path resolution
To perform any operation on a named file, the system resolves the path by walking the directory tree component by component. In early UNIX, the lookup started at a known inode (the root or the process's current directory), read the directory to find the next component's i-number, and repeated until the last component was resolved[3](https://www.cis.upenn.edu/~bcpierce/courses/dd/papers/thompson78unix.pdf). Modern Linux adds a caching layer: the Virtual File System, the kernel layer providing the filesystem interface to user programs, searches the directory entry cache (dcache) to translate a pathname into a dentry quickly. Dentries live in RAM and are never saved to disc; they exist only for performance, and a cache miss forces the VFS to call the parent directory's `lookup()` method to load the inode[8](https://www.kernel.org/doc/html/latest/filesystems/vfs.html?highlight=inode).
Path walk cost grows with the number of components, because resolving the last component requires locating all previous ones. On fast storage this software cost becomes visible: researchers report that nearly 50% of file operations in a network file system workload concern metadata, and that on byte-addressable non-volatile memory the tree walk dominates metadata system calls[5](https://doi.org/10.1145/3620673).
## Directory indexing at scale
A linear array of directory entries performs poorly in large directories, so file systems index them. ext3 introduced a hashed btree (htree), carried into ext4, keyed on a hash of the entry name; a lookup computes the hash of the desired name and descends to the leaf node whose hash range contains it, much as in a B-tree[4](https://kernel.org/doc/html/latest/filesystems/ext4/directory.html). The hash value is 31 bits, and interior nodes are hidden inside the directory file disguised as empty entries for backward compatibility with ext2[4](https://kernel.org/doc/html/latest/filesystems/ext4/directory.html). The traditional tree-based namespace also makes recursive traversal expensive, because entries of different directories are physically scattered on the device; in one experiment, traversing the hierarchy occupied nearly 80% of the time of a recursive `ls -R`, and sequential directory reading performed 4.08 times better than random reading[5](https://doi.org/10.1145/3620673).
## History
The hierarchical file system traces to Multics, which in 1969 pioneered the directory tree structure, path names in the `/home/user/documents/file.txt` style, working directories, and relative and absolute paths[9](https://people.cs.rutgers.edu/~pxk/articles/big-ideas-fs.html). Multics's stated goals included hierarchical structures of information for system administration, and its file system was integrated with the memory access system so programs accessed files by making memory references[10](https://multicians.org/history.html). A directory there was defined as a file system container for segments, links, or other directories[11](https://multicians.org/mgd.html).
When Thompson and Ritchie designed UNIX, they took the directory tree idea from Multics but pared it down to a simpler system, storing directories on disk like regular files[12](https://pages.cs.wisc.edu/~bart/537/lecturenotes/s25.html). Interestingly, very early UNIX systems allowed an arbitrary directed graph of directories with regular files linked in at arbitrary places; administration of such a structure became so chaotic that later systems were restricted to a directory tree[3](https://www.cis.upenn.edu/~bcpierce/courses/dd/papers/thompson78unix.pdf). A 1987 study of UNIX users at [Carnegie Mellon University](https://www.edgepedia.org/carnegie-mellon-university) found that most directories in practice were organized as trees with few levels, with some nodes serving as file storage areas and others as switch nodes used mainly during search[13](https://www.sciencedirect.com/science/article/pii/S002073738780069X).
## Case sensitivity and naming rules
How directories treat name case varies by system. Linux file systems treat file and directory names as case-sensitive, so `FOO.txt` and `foo.txt` are distinct files[14](https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity). Windows is case-insensitive by default but supports per-directory case sensitivity through an attribute flag, a feature introduced in [Windows 10](https://www.edgepedia.org/windows-10) build 17107 and exposed as the extended attribute `system.wsl_case_sensitive`; changing the flag requires an empty directory and elevated permissions[14](https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity). APFS, Apple's file system, is case-sensitive on iOS and available in case-sensitive and case-insensitive variants on macOS, with case-insensitive the default; it preserves the case and Unicode normalization of filenames on disk in all variants[15](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html).
## Flat namespaces and simulated directories
Not every storage system keeps a real directory tree. [Amazon S3](https://www.edgepedia.org/amazon-s3)'s data model is a flat structure: a bucket stores objects and there is no hierarchy of subbuckets or subfolders. The console and SDKs infer a logical hierarchy from key-name prefixes and the `/` delimiter, and the console creates folders as zero-byte objects whose key is the folder prefix plus the delimiter[7](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html). Object key names are case-sensitive and limited to 1,024 bytes encoded in UTF-8[7](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html). Google Cloud Storage offers both flat and hierarchical namespace buckets; in flat buckets there are no directories, and tools interpret the slash in an object's name as a delimiter to simulate folders, with the caveat that deeply nested directory-like structures lack the listing performance of a native file system[16](https://docs.cloud.google.com/storage/docs/objects).
Research continues into alternatives to the tree. FlatFS and FlatFS+ index file metadata directly by full hierarchical path in a flat namespace while presenting a compatible hierarchical view, shortening path walk to a single lookup and improving locality for directory range operations[5](https://doi.org/10.1145/3620673) • [17](https://www.usenix.org/system/files/atc22-cai.pdf).
## Human factors
The tree shape also reflects how people actually work. A study asking 296 participants to retrieve 1,131 of their active files, analyzing 5,035 navigation steps, found folder structures were shallow, with files retrieved from a mean depth of 2.86 folders and small folders (a mean of 11.82 files) containing many subfolders (mean 10.64). Navigation succeeded for 94% of files, averaging 14.76 seconds, and retrieval time and success depended on folder size and depth, which the authors read as users adaptively avoiding deep structure and large folders[6](https://onlinelibrary.wiley.com/doi/abs/10.1002/asi.21415). Earlier studies of DOS, Windows, OS/2, and Macintosh users similarly found that users preferred location-based finding for its reminding function, avoided elaborate filing schemes, and archived relatively little information[18](https://homepages.cwi.nl/~steven/sigchi/bulletin/1995.3/barreau.html).
## References
1. [A General-Purpose File System For Secondary Storage (Daley & Neumann, Multics)](https://www.landley.net/history/mirror/unix/multics/fjcc4.html)
2. [About Directory Management, Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/fileio/about-directory-management)
3. [The UNIX Time-Sharing System (Thompson & Ritchie, Bell Laboratories)](https://www.cis.upenn.edu/~bcpierce/courses/dd/papers/thompson78unix.pdf)
4. [Directory Entries, ext4 documentation, The Linux Kernel documentation](https://kernel.org/doc/html/latest/filesystems/ext4/directory.html)
5. [Exploiting Flat Namespace to Improve File System Metadata Performance on Ultra-Fast, Byte-Addressable NVMs, ACM Transactions on Storage (2024)](https://doi.org/10.1145/3620673)
6. [The effect of folder structure on personal file navigation (Bergman, 2010), JASIST](https://onlinelibrary.wiley.com/doi/abs/10.1002/asi.21415)
7. [Naming Amazon S3 objects, Amazon Simple Storage Service User Guide](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html)
8. [Overview of the Linux Virtual File System, The Linux Kernel documentation](https://www.kernel.org/doc/html/latest/filesystems/vfs.html?highlight=inode)
9. [The Evolution of File Systems (P. K. Kaiser, Rutgers University)](https://people.cs.rutgers.edu/~pxk/articles/big-ideas-fs.html)
10. [Multics History, multicians.org](https://multicians.org/history.html)
11. [Multics Glossary, multicians.org](https://multicians.org/mgd.html)
12. [CS 537 Notes: Directories, University of Wisconsin](https://pages.cs.wisc.edu/~bart/537/lecturenotes/s25.html)
13. [Structure of a directory space: a case study with a UNIX operating system, International Journal of Man-Machine Studies (1987)](https://www.sciencedirect.com/science/article/pii/S002073738780069X)
14. [Case Sensitivity, Microsoft Learn (WSL)](https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity)
15. [Apple File System FAQ, Apple Developer Documentation](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html)
16. [About Cloud Storage objects, Google Cloud Documentation](https://docs.cloud.google.com/storage/docs/objects)
17. [FlatFS: Flatten Hierarchical File System Namespace on Non-volatile Memories, USENIX ATC 2022](https://www.usenix.org/system/files/atc22-cai.pdf)
18. [Finding and Reminding: File Organization from the Desktop (Barreau & Nardi), SIGCHI Bulletin 1995](https://homepages.cwi.nl/~steven/sigchi/bulletin/1995.3/barreau.html)
---
*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Software and programming › Operating systems › File systems*
*Initially written Sep 17, 2026 · Reviewed: Oct 15, 2026 · Edited: Oct 15, 2026 · Last review: Oct 15, 2026*
*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*
License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license