Editing Filename extension (section)

== Operating system and file system support ==
The [[Multics]] file system stores the file name as a single string, not split into base name and extension components, allowing the "." to be just another character allowed in file names. It allows for variable-length filenames, permitting more than one dot, and hence multiple suffixes, as well as no dot, and hence no suffix. Some components of Multics, and applications running on it, use suffixes to indicate file types, but not all files are required to have a suffix — for example, executables and ordinary text files usually have no suffixes in their names.

File systems for [[UNIX-like]] operating systems also store the file name as a single string, with "." as just another character in the file name. A file with more than one suffix is sometimes said to have more than one extension, although terminology varies in this regard, and most authors define ''extension'' in a way that does not allow more than one in the same file name.{{citation needed|date=November 2023}} More than one extension usually represents nested transformations, such as <code>files.tar.gz</code> (the <code>.tar</code> indicates that the file is a [[tar (computing)|tar archive]] of one or more files, and the <code>.gz</code> indicates that the tar archive file is compressed with [[gzip]]). Programs transforming or creating files may add the appropriate extension to names inferred from input file names (unless explicitly given an output file name), but programs reading files usually ignore the information; it is mostly intended for the human user. 
It is more common, especially in binary files, for the file to contain [[File format#Internal metadata|internal]] or [[File format#External metadata|external]] metadata describing its contents.
This model generally requires the full filename to be provided in commands, whereas the metadata approach often allows the extension to be omitted.

[[Compatible Time-Sharing System|CTSS]] was an early operating system in which the filename and file type were separately stored.  Continuing this practice, and also using a dot as a separator for display and input purposes (while not storing the dot), were various [[Digital Equipment Corporation|DEC]] operating systems (such as [[RT-11]]), followed by [[CP/M]] and subsequently [[DOS]].

In [[DOS]] and 16-bit [[Microsoft Windows|Windows]], file names have a maximum of 8 characters, a period, and an extension of up to three letters. The [[File Allocation Table|FAT]] file system for DOS and Windows stores file names as an 8-character name and a three-character extension. The period character is not stored.

The [[High Performance File System]] (HPFS), used in Microsoft and [[IBM]]'s [[OS/2]] stores the file name as a single string, with the "." character as just another character in the file name. The convention of using suffixes continued, even though HPFS supports extended attributes for files, allowing a file's type to be stored in the file as an extended attribute.

Microsoft's [[Windows NT]]'s native file system, [[NTFS]], and the later [[ReFS]], also store the file name as a single string; again, the convention of using suffixes to simulate extensions continued, for compatibility with existing versions of Windows. In [[Windows NT 3.5]], a variant of the FAT file system, called [[VFAT]] appeared; it supports longer file names, with the file name being treated as a single string.

[[Windows 95]], with VFAT, introduced support for long file names, and removed the 8.3 name/extension split in file names from non-NT Windows.

The [[classic Mac OS]] disposed of filename-based extension metadata entirely; it used, instead, a distinct file [[type code]] to identify the file format. Additionally, a [[creator code]] was specified to determine which application would be launched when the file's [[Icon (computing)|icon]] was [[double-click]]ed.<ref>{{cite web|url=https://livecode.byu.edu/helps/file-creatorcodes.php|title=Mac Creator and File Type codes|accessdate=2022-09-02|website=livecode.byu.edu}}</ref> [[macOS]], however, uses filename suffixes as a consequence of being derived from the UNIX-like [[NeXTSTEP]] operating system, in addition to using type and creator codes.

In Commodore systems, files can only have four extensions: PRG, SEQ, USR, REL. However, these are used to separate data types used by a program and are irrelevant for identifying their contents.

With the advent of [[graphical user interface]]s, the issue of file management and interface behavior arose. Microsoft Windows allowed multiple applications to be [[file association|associated]] with a given extension, and different actions were available for selecting the required application, such as a [[context menu]] offering a choice between viewing, editing or printing the file. The assumption was still that any extension represented a single file type; there was an unambiguous mapping between extension and icon.

When the [[Internet]] age first arrived, those using Windows systems that were still restricted to [[8.3 filename|8.3]] filename formats had to create web pages with names ending in <code>.HTM</code>, while those using [[Mac (computer)|Macintosh]] or UNIX computers could use the recommended <code>.html</code> filename extension. This also became a problem for programmers experimenting with the [[Java (programming language)|Java programming language]], since it ''requires'' the four-letter suffix <code>.java</code> for [[source code]] files and the five-letter suffix <code>.class</code> for Java [[compiler]] [[object code]] output files.<ref>{{cite web
|url=http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
|title=javac – Java programming language compiler
|publisher=Sun Microsystems, Inc.
|year=2004
|quote=Source code file names must have .java suffixes, class file names must have .class suffixes, and both source and class files must have root names that identify the class.
|access-date=2009-05-31 }}</ref>