File extensions

Poll without page-refresh

Article on other languages:

	del.icio.us
	Digg
	Furl
	Reddit
	Rojo
	Add to OnlyWire

A filename extension is a suffix to the name of a computer file applied to indicate the encoding convention (file format) of its contents. In some operating systems (for example Unix) it is optional, while in some others (such as Windows) it is a requirement. Some operating systems limit the length of the extension (such as DOS and OS/2, to three characters) while others (such as Unix) do not. Some operating systems (for example RISC OS) do not use file extensions.

1 Usage
2 Historical limitations
3 The need for more
4 Security issues
5 Relation to Internet content types
6 See also
7 References
8 External links

Usage

Filename extensions can be considered a type of metadata. They are commonly used to infer information about the way data might be stored in the file. The description above is meant to mostly explain the intent of filename extensions: an exact definition, giving the criteria for deciding what part of the file name is its extension, belongs to the rules of the specific filesystem used; usually the extension is the substring which follows the last occurrence, if any, of the dot character (e.g. txt is the extension of the filename readme.txt, html the extension of mysite.index.html).

On filesystems of mainframe systems such as MVS, VMS, and PC systems such as CP/M and derivative systems such as MS-DOS, the extension is a separate namespace from the filename. Under Microsoft's DOS and Windows, some extensions, including EXE, COM, BAT, and CMD, indicate that a file is an executable program. This is different from Unix-like operating systems, where a suffix is not a separate namespace, and where even having a suffix is voluntary, as file system permissions are used to decide whether a file is executable.

With the advent of graphical user interfaces, the issue of file management and interface behavior arose. Microsoft Windows allowed multiple applications to be 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.

Pre-OS X versions of the Mac OS disposed of filename extensions entirely, instead using a 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 was double-clicked. Mac OS X, however, uses filename suffixes, as well as type and creator codes, as a consequence of being derived from the Unix-like NEXTSTEP operating system, which did not have type or creator code support in its file system.

Historical limitations

Filename extensions were used in Digital Equipment Corporation (DEC) operating systems (for example, TOPS-10, OS/8 and RT-11). CP/M adopted the convention and MS-DOS, as a re-implementation of CP/M, did so as well.

The DEC operating systems internally split the filename into a "base name" and a filename extension, with the "base name" limited to five to eight characters (initially nine in RSX and VMS) and the extension limited to two or three characters; when a filename/filename extension combination was typed in commands, a dot (.) was placed between the filename and filename extension. CP/M worked the same way; the filename was limited to eight characters and the filename extension was limited to three characters, with a dot between them. Early versions of the FAT filesystem used in MS-DOS and Microsoft Windows imposed the same limitations. This is sometimes referred to as the 8.3 filename convention, and since the word filename is eight letters long and ext is a reasonable abbreviation for extension, it can be generalized as:

FILENAME.EXT

When doing a file listing, the base name and extension would be separated by spaces, much like this:

Volume in drive A: is LINUX BOOT 
 Volume Serial Number is 2410-07EF
 Directory for A:\

 LDLINUX  SYS      5480 1999-04-19  23:24 
 VMLINUZ         530921 1999-04-19  23:24 
 BOOT     MSG       559 1999-04-19  23:24 
 EXPERT   MSG       668 1999-04-19  23:24 
 GENERAL  MSG       986 1999-04-19  23:24 
 KICKIT   MSG       979 1999-04-19  23:24 
 PARAM    MSG       875 1999-04-19  23:24 
 RESCUE   MSG      1020 1999-04-19  23:24 
 SYSLINUX CFG       420 1999-04-19  23:24 
 INITRD   IMG    878502 1999-04-19  23:24 
        10 files           1,420,410 bytes
                              35,840 bytes free

This use of spaces often led to confusion with novice DOS users, who thought of the "." as part of the file's identifier, rather than merely a convention for separating the two components of that identifier.

The need for more

The filename extension was originally used to easily determine the file's generic type. The need to condense a file's type into three characters frequently led to inscrutable extensions. Examples include using .GFX for graphics files, .TXT for plain text, and .MUS for music. However, because many different software programs have been made that all handle these data types (and others) in a variety of ways, filename extensions started to become closely associated with certain products—even specific product versions. For example, early WordStar files used .WS or .WSn, where n was the program's version number. Also, filename extensions began to conflict between separate files. One example is .rpm, used for both RPM Package Manager packages and RealPlayer Media files;^[1] others being .qif, shared by DESQview fonts, Quicken financial ledgers, and QuickTime pictures,^[2], and .gba, shared between GrabIt scripts and Game Boy Advance ROM images.^[3]

Some other operating systems such as Multics that used filename extensions generally had much more liberal sizes for filenames. Many allowed full filename lengths of 14 or more characters, and maximum name lengths up to 255 were not uncommon. The file systems in operating systems such as Unix stored the file name as a single string, not split into base name and extension components, with the '.' being just another character allowed in file names. Such systems generally allow for variable-length filenames, permitting more than one dot, and hence multiple suffixes. Some components of Multics and Unix, and applications running on them, used suffixes, in some cases, to indicate file types, but they did not use them as much — for example, executables and ordinary text files had no suffixes in their names.

The High Performance File System (HPFS), used in Microsoft and IBM's OS/2 also supported long file names, and didn't divide the file name into a name and an extension. However, the convention of using suffixes continued, even though HPFS supported extended attributes for files, allowing a file's type to be stored with the file as an extended attribute.

In addition, Microsoft's Windows NT's native file system, NTFS, supported long file names and didn't divide the file name into a name and an extension, but again, the convention of using suffixes to simulate extensions continued, for compatibility with existing versions of Windows.

As the Internet age arrived, it was possible to discern who was using Windows systems to edit their web pages versus who used Macintosh or Unix computers, since the Windows users were generally restricted to ending their web page filenames in .HTM (instead of .html). This also became a problem with programmers experimenting with the Java programming language, since it required source code files to have the four-letter suffix .java and compiled object code output files to have the five-letter .class suffix.

Eventually, Windows introduced support for long file names, and removed the 8.3 name/extension split in file names, in an extended version of the commonly used FAT file system called VFAT. VFAT first appeared in Windows NT 3.5 and Windows 95. The internal implementation of long file names in VFAT is largely considered to be a kludge, but it removed the important length restriction, and allowed files to have a mix of upper case and lower case letters, on machines that would not run Windows NT well. However, the use of three-character extensions under Microsoft Windows has continued, originally for backward compatibility with older versions of Windows and now by habit, along with the problems it creates.

Security issues

The default behavior of Windows Explorer, the file browser provided with Windows, is for file extensions not to be shown. Malicious users have tried to spread computer viruses and computer worms by using file names formed like LOVE-LETTER-FOR-YOU.TXT.vbs. The hope is that this will appear as LOVE-LETTER-FOR-YOU.TXT, a harmless text file, without alerting the user to the fact that it is a harmful computer program, in this case written in VBScript.

Some similar historical Microsoft Windows security issues are discussed under COM file.

Later Windows versions (starting with Windows XP Service Pack 2 and Windows Server 2003) included customizable lists of file extensions that should be considered 'dangerous' in certain 'zones' of operation, such as when downloaded from the web or received as an e-mail attachment. Modern antivirus software systems also help to defend users against such attempted attacks where possible.

There have been instances of malware crafted to exploit vulnerabilities in some Windows applications which could cause a stack-based buffer overflow when opening a file with an overly long, unhandled file extension.

Relation to Internet content types

In network contexts, files are regarded as streams of bits and do not have filenames or extensions.

In the internet protocol suite the information about a certain type relating to a certain bitstream is encoded in the MIME Content-type of the stream, represented by a row of text in a block of text preceding the stream, such as:

Content-type: text/plain

BeOS, whose BFS file system supports extended attributes, would tag a file with its MIME Content-type as an extended attribute. The KDE and GNOME desktop environments associate a MIME Content-type with a file by examining both the filename suffix and the contents of the file, in the fashion of the file command, as a heuristic. They choose the application to launch when a file is opened based on the MIME Content-type, reducing the dependency on filename extensions. Mac OS X uses both filename extensions and mime types, as well as file type codes, to select a Uniform Type Identifier by which to identify the file type internally.