When was the term ‘directory’ replaced by ‘folder’?

Question

I started using computers with MS-DOS and as far as I can remember the data structure holding files was called a directory (it held other directories as well), DIR is still used to list the content of such structure. When I transitioned to Windows XP--I didn't go through the Win 95, 98, 2000 phase--the similar structure was called a folder and today you barely hear directory among regular users. So when the naming changed and why? Was directory a FAT16 structure or one or the other had attributes or other technical or low level differences?

Answer 1

Directory is a filesystem concept. Folder is a user-level concept.

From its beginning in the 1980s, the Macintosh GUI (and possibly other GUIs before it) only talked about "folders" and showed them on-screen as manila folders.

In the MS-DOS world, it was still about "directories". Windows, up to Windows 3.1 I believe, stuck with the MS-DOS concepts because people were still using DOS daily. File handling in Windows was done mostly through the File Manager, which navigated a hierarchical directory structure reflecting exactly what was on the disk.

Starting with Windows 95, the metaphor morphed into a more modern form and the word "folder" became the norm. The Windows Shell handled all File Explorer windows, plus the desktop, but was not limited to showing files in the way they were physically stored in a directory. There were abstract folder-like objects such as the Recycle Bin and the Fonts folder, and the desktop itself, and My Documents. Concepts such as Network Neighbourhood represent things that are hierarchical but aren't quite directories.

Windows user interface guidelines started to move away from the concept of the C: drive and all its directories, and encouraging applications to store files automatically under the Shell's My Documents folder unless the user chose otherwise. Office, of course, led the way to this approach.

This merged nicely with multiple-user concepts being introduced with Windows NT 3.5 and 4.0, with each user seeing their own My Documents folder in a convenient, predictable way, while physically it was stored in a user-specific directory somewhere under C:\WINNT\Profiles to help enforce access restrictions.

Today, the folder concept is stretched further with things like OneDrive or DropBox, which appear as folders in File Explorer and are based on physical disk directories but have some abstract extent into the Cloud, to the point where you may not know exactly if a given file you see on-screen is stored locally.

In summary, a directory is always a folder, but a folder can be many other things, and modern non-techie users see everything as a folder and have no concept of a directory.

Answer 2

TL;DR:

No, 'Directories' were never replaced by 'Folders'. They are the same.

---

The names just represent different views:

• Directory is the data structure holding information about files (and other directories). It is what OS and all applications work with.

• Folder is the mental image GUI systems invoke by using icons looking somewhat like folders. It's part of the desktop metaphor the Windows GUI uses.

The different viewpoint is already present with 16-bit Windows (3.1, etc.) running on DOS. When looking at a drive from DOS with DIR it shows directories. Looking at the same drive using the Windows file manager it will show neat folders.

A folder is to a directory as a document is to a file (*1) - simply an alternative name for users to handle data in a office-like fashion, not caring about terms those techno nerds came up with. :))

So when the naming changed and why.

It never did.

It may just be that you're nowadays more in contact with people who are non-techies - as well as reading documentation rather made for them, only using those metaphorical names of Folders and Documents instead of Directories and Files.

---

*1 - Well, one may restrict the term 'document' to 'data file', but that's kind of moot as in the original GUI definitions no files other than data files were user visible. The GUI metaphor of a desktop doesn't use programs, but various tools represented as icons (or properties). The user should not have to care about how a function is provided - or what a program is at all.

Likewise there were no drives, but drawers. Drawers were where files and folders could be put. The mundane idea of them being a specific user side visible drive with cryptic names only crept in when GUIs were add-ons - like windows.

Answer 3

1984 Mac: They did mean different things

The original file system of the Macintosh was called MFS (Macintosh File System). It was released with the first Macs in 1984. In this file system, "directories" and "folders" did actually have different meanings.

MFS is a "flat" file system. Each floppy disk ("volume") contains exactly one directory, a table that contains information about all of the files on the volume:

A volume contains descriptive information about itself, including its name and a file directory that lists information about files contained on the volume; it also contains files. The files are contained in allocation blocks, which are areas of volume space occupying multiples of 512 bytes.

Apple Computer, 1985. Inside Macintosh, volume II, p. II-79

Every file on the volume is listed in this one directory.

Each directory entry has a 16-bit signed integer field called fdFldr, the "folder number" of the file. The Finder created new folders by choosing another number. Files were placed into folders by setting their fdFldr. The number of folders was limited only by the size of the fdFldr field.

This system was horribly inefficient. To iterate through all of the files in a single folder, you had to iterate through every file on the volume, checking to see if its fdFldr matched your desired folder.

So they were different things in MFS.

1986 Mac: They now mean the same thing

By 1986, Apple developed an improved filesystem called HFS (Hierarchical File System). Directories were now nested. It was much more efficient; when you iterated a directory, you accessed just those files in that directory. Apple acknowledged that the folders in MFS had been merely an illusion:

The hierarchical directory structure is equivalent to the user's perceived desktop hierarchy, where folders contain files or additional folders. In the 64K ROM version of the File Manager, however, this desktop hierarchy was essentially an illusion maintained completely by the Finder (at considerable expense). The introduction of an actual hierarchical directory containing subdirectories greatly enhances the performance of the Finder by relieving it of this task.

Apple Computer, 1986. Inside Macintosh, volume IV, p. IV-90.

With HFS, Apple also acknowledged that folders and directories were now the same thing:

directory: A subdivision of a volume that can contain files as well as other directories; equivalent to a folder.

ibid, glossary p. IV-312

So now they were the same thing. (Well, technically folders could only be subdirectories, because root directories were volumes.)

Answer 4

I believe this is a distinction without a difference. As described reasonable well in the Wikipedia article on "directory", folder is more of a way of describing the use of a directory for holding user files. But there is no fundamental difference - directory and folder are two names for the same thing.

In fact (though someone will likely prove me wrong with examples in specific operating systems), I don't think there has been any fundamental change at the operating system (e.g., the many versions of Microsoft Windows) level. Rather, the change is among regular users. FAT16, FAT32, NTFS, HPFS (OS/2), APFS (Apple File System) all seem to refer internally to directories and it is only at the user level that the folder designation is used. Of course, the folder icons used by modern operating systems, combined with many users never using the command line, increases the use of "folder" among regular users.

Go to the command line and it is mkdir, cd, pwd, etc. Not mkf or cf or pwf. The change to folder is external, not internal.

Answer 5

Folder is a concept that probably¹ originated with the MacOS operating system (note the capital M, it's the original Macintosh operating system, not the one that used to be called OS X).

The term "folder" is a user interface concept that means "container for documents". Folders are implemented in macOS as file system directories but they are not identical. To understand why this is, you have to understand how documents are implemented. Documents are usually implemented as files². However a document can sometimes be a "bundle" which is a collection of files in a directory. The top level directory has a special attribute set that makes it look like a single entity to the graphical user interface. The most obvious examples are Macintosh applications. These look like single objects in the GUI but, from the command line, if you list them, you can see they are directories.

jeremyp@eleanor dev % ls -l /System/Applications/TextEdit.app        
total 0
drwxr-xr-x  8 root  wheel  256  2 Dec 11:37 Contents
jeremyp@eleanor dev % ls -l /System/Applications/TextEdit.app/Contents 
total 16
-rw-r--r--   1 root  wheel  9263  2 Dec 11:37 Info.plist
drwxr-xr-x   3 root  wheel    96  2 Dec 11:37 MacOS
-rw-r--r--   1 root  wheel     8  2 Dec 11:37 PkgInfo
drwxr-xr-x  59 root  wheel  1888  2 Dec 11:37 Resources
drwxr-xr-x   3 root  wheel    96  2 Dec 11:37 _CodeSignature
-rw-r--r--   1 root  wheel   457  2 Dec 11:37 version.plist

So, in summary, a folder is a directory³, but a directory is not always a folder.

The same may not apply on Windows which does not have the same concept of bundles AFAIK.

---

¹It may be that Apple appropriated the terminology from e.g. Xerox

²The term "file" has always been a source of annoyance to me. In dead tree technology, a file is a folder or a binder containing documents, so, really a file should be analogous to a folder/directory. I guess the terminology comes from the punched card days where each card would be a record and a stack of them would be a file.

³Except when it's not. Some applications use the term folder to refer to things that are not implemented as directories e.g. the mail app lets you have folders associated with mailboxes. The Apple mail app implements these as a combination of sqlite files and a directory, but it doesn't have to.

Answer 6

In my point of view, this is more a GUI vs. command line differentiation. Within a *nix-shell, I still "mkdir" and not "mkfolder". But in most of the window managers (not all), the icon resembles a physical folder. Same with the transition from MS-DOS to Windows.

Answer 7

Since the question body seems particularly focused on Windows, I am going to answer the question of when the name change happened in Windows. This answer is pretty easy: the name change happened in Windows 95.

Back in Windows 3.x, containers for files were named ‘directories’, just like they were in DOS:

Windows 95 introduced the name ‘folder’:

The name change happened apparently pretty early in development: Toasty Tech’s gallery of screenshots shows that directories were named ‘folders’ already in Chicago build 58. This was before the introduction of FAT32 (which only appeared in Windows 95 OSR2), and even before long file name support was implemented.

Keep in mind, though, that in Windows, ‘folder’ is a name a bit broader than ‘directory’, in that it covers not only containers for files that usually correspond to records on storage media, but also ‘virtual folders’ like the Control Panel, Network Neighborhood or My Computer, which like directories are presented in the shell as having enumerable contents, but don’t have actual pathnames and act only as symbolic representations of more abstract resources. And at least at one point during development, the notion was going to be even more expansive than that. One mock-up found in the Microsoft Windows “Chicago” Reviewer’s Guide shows the Explorer being used to read mail inside an ‘Info Center’.

As for motivation for the new name, I can only speculate. Part of it was probably Macintosh envy; on the Mac, containers for files presented in the UI were called ‘folders’ (and, as @DrSheldon’s answer explains, initially did not correspond to directories in the disk format sense in the non-hierarchical file system used by the OS). Part might have been a desire to reflect the broadening of the abstraction to cover entities other than on-disk directories. But it also made sense on its own terms: another reason might have been a desire to reinvigorate the desktop metaphor. Notice for example, how Windows 3.x uses a folder icon for directories, and a filing cabinet icon for the file manager. Chicago simply changed the terminology to match: the new file manager was called the ‘Cabinet Explorer’ (though the ‘Cabinet’ part was later dropped), while directories were renamed to ‘folders’. And files, of course, are represented by icons showing sheets of paper. The renaming made the terminology coherent with the icons, and made it again a live metaphor for data organisation in an office.

Answer 8

Let's consider the classic definition of directory:

a book listing individuals or organizations alphabetically or thematically with details such as names, addresses, and phone numbers.

When computer scientists came up with the concept of a list of files stored in some organization, a directory immediately came to mind. All kinds of file systems had a directory listing for a list of files on a disk. Later, these directories could be nested using additional directory listings.

Now, we can look at the ordinary definition of folder:

a folding cover or holder, typically made of stiff paper or cardboard, for storing loose papers.

When computers first gained a GUI, there were analogies abound. The workspace was called a Desktop, deleted files would go in the Trash or Recycle Bin, and files were typically Documents. Since Documents could be analogous to printed media (also called documents), organizing those Documents would place them into Folders.

It's important to note that Folders are a GUI concept, and a Directory is a CLI concept. In most GUI systems, a Directory is often exposed as a Folder, but Folders can be other kinds of things as well. For example, Windows has various Magic Folders that can expose administrator tools and so on that are not actually stored in a real Directory. Similarly, most file systems can have Directories that are special, such as mount points and junctions/links.

Modern users, such as programmers, that are aware of the distinction, will often be specific about using the correct terminology. If they ask you to open a terminal, you'll almost certainly be working with directories, while if they ask you to open a File Explorer (or equivalent), they'll refer to the things they're working with as Folders.

As a metaphor, you can say that Directories are to Folders, as Files are to Documents. They mean essentially the same thing, but are slightly different in actual implementation and have slightly different meanings. In a CLI, you don't refer to a Directory as a Folder, and in a GUI, you don't refer to a Folder as a Directory.

Finally, as an example in programming, some languages use functions, and some languages use methods. They mean the same thing--a block of code to be translated to machine instructions--but the language you're using will reflect the terminology of the language itself to avoid confusion. In Java, you write methods, and in JavaScript, you write functions. Both accept parameters, have a return type, etc, but are simply called different things, as they were developed by different people.

Answer 9

The terms are essentially interchangeable metaphors for the same thing, but they are coming from different directions.

From one direction, you can start with a physical device (perhaps called a "drive", "disk", "volume", or "device") which stores a number of pieces of data (perhaps called "records" and "data sets", "inodes", or "files"). You want a way to reference them without knowing their physical location.

This leads to metaphors like a "directory", "catalog", or "index" - a list of names, pointing to their corresponding locations on the storage medium.

From the other direction, you have a number of logical objects (perhaps called "documents", or just "files"), and you want a way to organize them, independent of their physical location.

This leads to metaphors like "folder", "drawer", or "area" - a physical location or object which contains other objects.

The "container" metaphor is slightly more abstract: there might or might not be a "directory" or "catalog" underneath; notably, the original Apple Macintosh had "folders" which were actually stored as a label against each file, the whole disk having a single directory listing all files. When that was replaced by the Hierarchical File System, the user interface didn't need to change, because it was already using an abstract metaphor. This is a general trend: hiding details behind additional layers of abstraction.

The "container" metaphor also fits well with window and mouse based UIs: you can "open" a folder, drag a file "out of" it and drop it "into" another. The "directory" metaphor is more suited to text-based and automated processing: you can "examine" the directory, "add" and "remove" entries, perhaps even edit it as though it was a text file.

Answer 10

On the PC, GEM (following the Lisa / Mac GUI) used "Folder" from its first release in 1985.

Answer 11

All these answers and no-one has yet mentioned the Xerox Star

The Star basically invented the desktop metaphor (though there may have been earlier traces with the Alto), from which Apple and Microsoft later got their ideas.

The Star desktop, like real office desks, could hold file drawers, folders, and files. This is the source of our use of 'folder' in a computer context.

The question is, of course, when the term 'folder' replaced 'directory'. This won't have happened overnight, even for Star users. Perhaps people using the Star always said 'folder', but certainly out there in the world, we still said (and some of us still do) say 'directory'. If pushed, I'll use 'folder' for items manifested by a GUI, but not for those name-to-metadata files implemented in file systems.

Answer 12

The relationship between the terms "directory" and "folder" is rather operating system dependent.

OS/400 (nowadays IBM i)

When the IBM AS/400 was released in 1988, its operating system was known as OS/400. OS/400 was renamed i5/OS in 2004, and then to IBM i in 2008, under which name it survives until today. OS/400 in turn is a direct descendant of CPF, the operating system of the IBM System/38 (announced in 1978, although apparently didn't actually ship to customers until the next year or the year after.) Like many, I'm not a big fan of its current name (which is very non-distinctive, and easily confusable with Apple iOS or Cisco IOS), so I'll just call it by its original name, OS/400.

OS/400 V3R1 (1994) introduced the Integrated File System (IFS) – a virtual filesystem layer which made multiple file systems, with very different underlying technologies, appear as part of a single POSIX-style directory hierarchy. IFS integrates together several different filesystems:

• / (root filesystem): POSIX-style filesystem, but with case-insensitive filenames
• /QOpenSys: POSIX-style filesystem, with case-sensitive filenames
• /QSYS.LIB: provides access to traditional OS/400 storage based on objects of various types organised into a single level of libraries; FILE (database files, corresponding to DB2 database tables) is just one of many object types
• /QLANSrv: filesystem of LAN Server/400, which was a port of OS/2 LAN Manager to OS/400. It provides an OS/2-style filesystem, so is case-insensitive, and lacks POSIX permissions
• /QOPT: CD-ROMs and DVD-ROMs (ISO 9660 and UDF)
• /QFileSvr.400: provides access to data on remote OS/400 systems (using an IBM proprietary protocol, over either SNA or TCP/IP)
• /QNTC: provides access to SMB/CIFS filesystems. At one point, IBM added embedded x86 servers to AS/400s which could run Windows NT (and later Linux), and QNTC was originally developed for them
• /QNetWare: provides access to NetWare filesystems via NCP. No longer supported. Like QNTC, QNetWare was originally intended for use with NetWare running on an embedded x86 server, but could also be used to talk to standalone NetWare servers.
• NFS (unlike other filesystems, doesn't have a fix mount point)
• /QDLS: Document Library Services. Used to store word processing documents

Now, you might be asking, what relevance all of this has to the question? Well, the root file system, /QOpenSys, /QLANSrv, /QOPT, /QNTC, /QNetWare and NFS are all hierarchical filesystems, composed of files and nested directories – just like you are used to from other platforms (Windows, Linux, etc.)

Whereas, /QSYS.LIB is not a hierarchical filesystem. It is composed of objects organised into a single-level of libraries – libraries cannot be nested, except for the exceptional case of the library QSYS, which directly contains every other library. Speaking in terms of OS/400's native (pre-IFS) APIs, a library is not a directory. However, libraries are directories for the purpose of the IFS API.

/QDLS by contrast is a hierarchical filesystem. And here's where we get to the bit directly relevant to the question: instead of "files" nested within hierarchical "directories", it contains "documents" nested within hierarchical "folders". /QDLS was designed for use with IBM's Office Automation products (i.e. DisplayWriter/400, and its predecessors DisplayWriter/36 and DisplayWriter/38; also OfficeVision/400, which could be integrated – via SNADS – with OfficeVision/MVS and OfficeVision/VM aka PROFS.) As such, it is a rather deeply legacy thing – it only supports MS-DOS-style 8.3 letter file names. And, just as a QSYS.LIB library is surfaced in IFS as a directory, so are QDLS folders surfaced in IFS as directories.

But, IBM documentation is generally rather careful to restrict the use of the word "folder" to QDLS. Calling a directory in /QOpenSys or a library under /QSYS.LIB a "folder" is strictly speaking incorrect.

Here's a summary and comparison:

Filesystem	Container Term	Item Term	Hierarchy	Max name length
/QSYS.LIB	library	object	single-level	10.6
/QDLS	folder	document	nested	8.3
/QOpenSys	directory	file	nested	255

Of course, from an IFS API viewpoint, they are all directories and files; but both QSYS.LIB and QDLS have their own native (non-IFS) APIs which don't use those terms. (In the case of QSYS.LIB, the term "file" is used, but to refer to a specific type of object, whereas for IFS every object is a file.)

The exception to my "generally" above is when it comes to the Windows-based GUI for remotely administering OS/400, "Navigator" (now "IBM Navigator for i", before that "iSeries Navigator", and before that "Client Access Navigator"). That application (and its documentation) uses the term "folders" even for directories and libraries, not just for QDLS folders. However, that's likely a sign of Windows influence, rather than being representative of OS/400's native terminology.

Windows

If we want to be pedantic about it – directories exist in the native Windows NT API, and the core (non-COM) Win32 API. Folders, by contrast, are implemented by the Windows Shell COM API (contained in SHELL32.DLL). From a programmer viewpoint, directories and folders are different things, because you use different APIs to manipulate them. A folder is a COM object, but not a kernel object; a directory is not a COM object, but it is a kernel object. In Windows NT, a directory is an object in the Windows NT kernel Object Manager (albeit, not a "Directory" object, rather a "File" object)–whereas folders are a purely user space concept within the Win32 environment subsystem, and the kernel knows absolutely nothing about them.

Now, it is true in many cases, a Shell folder corresponds one-to-one with a directory; but it doesn't have to. There are also "virtual folders" for which there is no corresponding filesystem directory – examples built-in to Windows include "Control Panel", "Printers", "Network Neighborhood", "My Computer". And if you create a Shell Namespace Extension – a DLL containing COM classes implementing the necessary Windows Shell COM interfaces, and the necessary registry entries to make Windows Shell load that DLL and instantiate those classes – you can even create your own virtual folders, to represent anything you like.

Windows Shell (SHELL32.DLL) was first introduced with Windows 95, and then ported to Windows NT as part of Windows NT 4.0. So, in Windows 3.x and Windows NT 3.x, officially speaking folders didn't exist yet, only directories. Some people may have used the term "folder" informally to mean a directory (e.g. in File Manager), or a Program Group (in Program Manager), but I'm not aware of any official Microsoft source (from that era) using the term.

OS/2

In OS/2 2.x and higher, the Workplace Shell (WPS) is conceptually quite similar to Windows SHELL32.DLL – the big difference being that instead of being implemented with COM, it is implemented with SOM.

However, there is a key terminological difference – what SHELL32.DLL calls "folders", WPS calls "containers". And while SHELL32.DLL has both "physical folders" (that correspond to directories), and "virtual folders" (that don't), to WPS only a physical folder is a "folder", whereas a "virtual folder" would be any container which is not a folder. Here's a table comparing their terminology:

Concept	Windows Shell term	Workplace Shell term
an entity represented by an icon	"item"	"object"
entity which contains other entities, represented by a window full of icons	"folder"	"container"
... which corresponds to a filesystem directory	"physical folder"	"folder"
... which doesn't correspond to a filesystem directory	"virtual folder"	(not aware of an official term, but any "container" which isn't a "folder")

(Source: I think this will become clear if you read the Workplace Shell Programming Guide against the Windows Shell Developer's Guide–although I'm not aware of any document that gives a direct comparison.)

Conclusion

So, as we see above, in some operating systems, the terms "directory" and "folder" have at least partially distinct meanings. But Windows and OS/2 draw a different (albeit related/overlapping) distinction between the two terms. And the OS/400 APIs (as opposed to the Windows-based administration GUI) uses the term "folder" in a completely different way, drawing a largely unrelated distinction between "directories" and "folders".

Answer 13

The Folder is of a higher level of abstraction than the directory. The ideas of the functionality of a folder was thought up before the folder was a concept, so file systems have some of it, but this is about the concepts.

The directory structure is tied to the hardware. A hard drive has a root directory and subdirectories. and files stored in them. At least originally. A folder is tied to a user interface. Not necessarily to a piece of hardware.

Why this is confusing is because the difference is rarely taken advantage of. But a place where it is used is in your start menu in Windows. Your start menu will show the content of your user's start menu AND the content of default users (or everyone's) start menu. And as another example, your MyDocuments folder could have subfolders named MyLocallyStoredDocuments, MyNetworkStoredDocuments and MyCloudStoredDocuments. Only 1 of those folders would logically be stored in your local dirfectory. but all 3 in the MyDocuments folder.