Talk:Filename extension

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Note icon
An image has been requested for this article. Please remove the image-needed parameter once the image is added.


  1. I heard that AutoDesk has recently claimed a trademark of the .dwg file extension. Can somebody confirm this and maybe add a section to the article about trademarking file extensions? Have there been any cases of file extension trademarks that were actually held up in court? The Donc (talk) 01:55, 6 March 2010 (UTC)
  1. Thankyou, Hephaestos, that most recent change (restoring the Win 3.x I deleted, but without the implication that it is an operating system) is an improvement.
  2. The article currently says 32-bit Windows operating systems include a patch at the interface level which simulates a limit of 256 characters; at the system level, the three-character limitation remains, albeit invisible to most users. This is certainly how VFAT and FAT32 work, but unless my memory is playing me false, NTFS uses "real" long filenames. Someone want to double check me before I make the change?

Tannin 09:22, 16 January 2003 (UTC)

The above don't look like questions; should they be in the comments section below?

Anyway, someone said

On systems with interpreter directives, command name extensions have no special significance, and are by standard practice not used, since the primary method to set interpreters for scripts is to start them with an single line specifying the interpreter to use (which could be viewed as a degenerate resource fork).

How is metadata in the file (on a Mac, in the file's data fork) like a degenerate resource fork? It doesn't sound any more reasonable than saying the single line is a degenerate extended attribute.

Iain Dalton (talk) 07:17, 14 January 2010 (UTC)


Filename extentions originated with dos. Unix doesn't *know* about filenmae extentions, it just happens to accept . as a legal chracter in a filename. (and when people started using linux on x86 a lot, they took their dos habits with them) Officially, unix uses magic numbers to identify file-types.

RISC OS doesn't use filename extentions at all.

So hmm, somehow this article should point this out better I think. - Kim Bruning 10:21, 19 Mar 2004 (UTC)

Officially. Actually not. make depends on extensions to work at all, and compiler front-ends choose the correct back-end by looking at each source file's extension (.c for C, .C for C++, .S for assembler, etc.). And the file utility is required (by the UNIX standard) to tell C source files from English text files - there's no reliable way to do this by looking at the file's contents.
The documentation on my system would seem to disagree with you: file uses what it calls "language tests" to determine things like whether or not a text file is C code; at no stage does it parse the filename and examine its "extension". make, on the other hand, does parse filenames, but only as a shortcut - it uses pattern matching (and it needn't just be suffix matching) to "guess" what commands need to be run. So while Kim's comment about Linux users "[bringing] their dos habits with them" is probably a bit off-base historically speaking, the fact remains that UNIX-type systems don't have a formal concept of filename extensions.
man file
 "... Once file has determined the character set used in a text-type file, it
      will  attempt  to  determine in what language the file is written.  The
      language tests look for particular strings (cf names.h) that can appear
      anywhere  in  the first few blocks of a file.  For example, the keyword
      .br indicates that the file is most likely a troff(1) input file,  just
      as  the  keyword  struct  indicates  a C program.  These tests are less
      reliable than the previous two groups, so they are performed last.  The
      language  test  routines  also test for some miscellany (such as tar(1)
      archives). ..."
(the "previous two groups" referred to are filesystem tests [to detect special files, symbolic links, empty files, etc] and magic number tests)
info make
"...   "Implicit rules" tell `make' how to use customary techniques so that
        you do not have to specify them in detail when you want to use them.
        For example, there is an implicit rule for C compilation.  File names
        determine which implicit rules are run.  For example, C compilation
        typically takes a `.c' file and makes a `.o' file.  So `make' applies
        the implicit rule for C compilation when it sees this combination of
        file name endings. ..."
- IMSoP 20:04, 27 Jun 2004 (UTC)
File name extensions most definitely did not originate with MS-DOS. Many OSes before MS-DOS had the notion of a file name with multiple components, whether the name was stored in the file system as a string with "."s separating the components or as multiple strings for each of the components. I think both CTSS and CMS had two-component file names with the components stored separately (and, I think, with a space separating them). Multics stored file names as strings, and had, by convention in userland, had suffixes for file types with a "." separating the rest of the file name and the suffix. DEC operating systems such as TOPS-10, various PDP-11 operating systems, and VMS used "." in file names to split the name into the main name and a suffix; I think at least some of them stored the file name in the file system as multiple components.
Unix followed in the Multics tradition, in which a file name was an arbitrary string at the file system API layer, but had conventional suffixes for many file types such as source and object files. MS-DOS probably followed CP/M. which followed in the DEC tradition. Guy Harris 00:52, 29 March 2006 (UTC)

responsibilities of email programs[edit]

from the article (emphasis mine):

It is clearly the responsibility of the e-mail program to warn the user of dangerous attachments, or to block their execution altogether, to stop at least the former kind of attack; handling the latter is entirely a matter of education and training, but its impact can be somewhat mitigated with the application of the principle of least privilege (including, but not limited to, sandboxing). Most programs already provide such protection (notably Eudora, which in the latest Windows versions even extends this functionality to the operating system by means of a shell extension).

Using "it is clearly" is usually a flag that warns that the next bit is going to be POV. So let's take a look.

Hmm, this paragraph seems to only hold true on MS windows, for *some* programs (ok, only programs with certain rather broken security features, alright, so only Outlook Express springs readily to mind). I haven't actually encountered the problem at all anywhere else. So it's not clear at all that the email program has to have any responsibility at all.

The prevalent opinion I've come into contact with is that the e-mail program should avoid taking on responsibilities it can't handle (such as determining what to do with attachments, other than saving them to the hard drive).

So perhaps that could use some NPOV-ing.

Kim Bruning 08:38, 10 Aug 2004 (UTC)

That paragraph may be good or bad. Regardless, I don't think it is relevant to discussion of filename extension. Windows and probably Windows alone uses a filename extension for hits of executable files. It is a problem of executing a malicious program but not of a filename extension. -- Taku 08:46, Aug 10, 2004 (UTC)


I think the article needs to be cleaned. Especially the part where it lists the file extensions/formats.

I suggest that the list of file extensions is removed, since there is already a separate page for that.


Rather than a separate page, I literally came to you for 2-3 links to some of the top-line File Extension list sites. I don't know who is making the rules for what is included, but I think of HTML links as a bibliography. You are citing your sources. Just make sure your sources don't go away. But the top File Extension HTML sites have been there FOREVER!

The first paragraph is factually incorrect. I am referring to "... executables, as permissions are used to decide whether a file is executable." The "magic" isn't just a number. It consists of any unique file header information that is stored in the first part of the file. On many Linux systems those files are in the /usr/share/file folder. You can actually look at the magic and magic.mime files to get an idea. All Unix operating systems first check the magic of the file to determine if a file that is flagged as being executable is in fact really executable. By that I mean the file may be a valid binary file for some system, but not the one you are on. If that fails they look for the first string at the start of the file to determine if some scripting program can interpret the script (run it). Ergo, the end of the first paragraph should be ".. executables. Unix-like systems use a combination of file permissions where a file is flagged as executable for a user, a group, or the world in conjunction with the "magic" of the file to determine whether a program can be run." Alternatively you can chop it even farther back in the paragraph as "... where a suffix is not a separate namespace." Cut the rest. It just confuses rather than enlightens the reader. At least now you know why you are cutting it. hhhobbit 18:02, 10 July 2007 (UTC)

File extensions in Mac OS X[edit]

Somebody should mention that filename extensions are also used by Mac OS X to identify file types. [1] [2] (And Apple's in-progress move to Universal Type Identifiers, but I digress.) æle  2006-03-28t02:30z

That's Uniform Type Identifiers. Guy Harris 21:57, 29 July 2006 (UTC)

Is the dot part of the extension?[edit]

Is the dot part of the extension or not? Softreviewer 19:15, 1 June 2006 (UTC)

"It depends." In many cases, I'd be inclined to say "no" - a table mapping file extensions to file type strings, applications to use on the file, etc. would probably have the name without the dot as the key. There's no guarantee of that, though. Guy Harris 02:00, 2 June 2006 (UTC)
Thank you. Softreviewer 17:39, 2 June 2006 (UTC)

Windows XP[edit]

Windows XP can also use file content to load program. However, I have only found MS office uses this feature. Try yourself: Create a Word Document, rename the file to an unrecognized extension, try to open it. It will still be opened by Word.


"Mac OS X, however, uses filename suffixes as a consequence of being derived from the Unix-like NEXTSTEP operating system, which did not have extension support in its file system."

Wouldn't the lack of support in its ancestor imply that it would NOT support them as a consequence? I'm reverting that line to an earlier version. Andy Christ 18:56, 27 June 2007 (UTC)

The person who "Fixed considerable numbers of conflations of "extension" with "suffix"" "fixed" something that wasn't a conflation of extension with suffix; the version you reverted is the correct version. Guy Harris 22:07, 27 June 2007 (UTC)

OS 9 and prior file type system[edit]

Perhaps some information (even a link) should be given about the system as seen in Mac OS 6(?), 7, 8, 9: the system of fourcc-like codes for type and creator (e.x. TEXT for text files, APPL for programs, MACS for system files, etc.). Link to articles: Type code, Creator code, OSType. I'm just not sure where put the details in the article. nneonneo 23:14, 9 July 2007 (UTC)

Opening sentences[edit]

"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."

Does this really apply on a modern Windows system? -Rushyo Talk 11:32, 25 September 2008 (UTC)

I think it's blatantly false: it is possible to create and use a file without a filename extension in Windows. --Keith111 (talk) 11:54, 4 February 2009 (UTC)

.java and .class[edit]

(Moved from my Talk page, as I think User:Oli Filth wants to discuss the article rather than me personally) --Nigelj (talk) 19:51, 31 May 2009 (UTC)


I've just noticed your edit at Filename extension. I have no reason or evidence to dispute you, but the ref you provided (as far as I can see) doesn't indicate that use of these extensions is/was mandatory, and neither does the "Common problems" page that links from it. Are you able to provide a better ref for this?

Best regards, Oli Filth(talk|contribs) 19:09, 31 May 2009 (UTC)

Hi Oli,

I haven't worked in Java for some years, but there are several points I can make:

  1. It's very hard to prove a negative.
  2. The tutorial lists only MS Windows versions from W2K onwards (all long-filename-compatible)
  3. It says "Be Careful When You Type: Type all code, commands, and file names exactly as shown."
  4. With my current javac on this machine, if I name the file 'HelloWorldApp.jav' or 'HelloWorldApp.txt', it will not compile.
  5. In the list of options available for the javac program, none mentions allowing other filename extensions
  6. In the list of options available for the javac program, there isn't one I can see to stop the compiled file being called 'HelloWorldApp.class'
  7. I remember all this being true when I first started messing with javac on Win95 and Win98 machines
  8. In those days there was no other way to compile java code besides the Sun-supplied javac program
  9. If you 'have no reason or evidence to dispute you', why am I doing all the research?

A non-logged-in user ( deleted this information earlier this evening, saying it "is simply not true". I didn't write it originally in this article, but I know that it simply is true. Now, the purpose of adding citations is so that any disputable facts can be verified. If you go to the Duck article and read "Duck is the common name for a number of species in the Anatidae family of birds", is it reasonable to start a discussion as to whether ducks really are birds, with no evidence at all to back up that they may not be? If people are going to delete and dispute and discuss every statement, even if they have "no reason or evidence to dispute" them, then it is going to be very hard work getting anywhere around here.

So, how about you go off and find a referenced way to get 'HelloWorldApp.jav' to compile into 'HelloWorldApp.cla', with proof that this technique would have worked circa 1995-1997, then we'll be able to say that there is something to discuss.

Thanks for your interest

--Nigelj (talk) 19:51, 31 May 2009 (UTC)

I guess the issue here is that it has been contested (even if it's by an anonymous IP), and it may be interpreted as some kind of WP:OR. If it is the case (and some primitive experiments with javac on my part seem to confirm this), then it's probably in some language/tools documentation from Sun. I'll take a look. Oli Filth(talk|contribs) 20:14, 31 May 2009 (UTC)
Well found, Oli. [3] is much better than the ref I provided. --Nigelj (talk) 14:30, 3 June 2009 (UTC)

Incorrect meaning[edit]

Extension is specifically a special portion of file name represented as a separate field inside filesystems that support extensions (FAT, NTFS), so it is not a simple suffix within the file name. Should be rewritten. —Preceding unsigned comment added by (talk) 07:18, 27 February 2011 (UTC)

re:My Page[edit]

re:My Page

My Advice:Follow tips below. -Start by writing a draft -Then make a jott list -Proofread and edit -Rewrite draft for final -Reread again (talk) 19:54, 24 April 2011 (UTC)

"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 filename extension."

Is this relevant? Any code whatsoever that's written in C is at risk of being vulnerable to remote code execution attacks. It has nothing to do with whether you're parsing a file name or an OGG container. —Preceding unsigned comment added by (talk) 05:06, 7 May 2011 (UTC)

 Rimmysingh</h1rimmysingh/h>  — Preceding unsigned comment added by (talk) 09:48, 25 November 2011 (UTC) 


The definition in the introduction states "a suffix seperated from the filename by a dot ….", hence the dot is not considered to be part of the extension. Yet all examples include the dot in the extension. (talk) 14:26, 3 March 2014 (UTC)

Suffix, not extension![edit]

The article mixes up the terms of "extension" and "suffix" badly. Generally, things at the end of filenames like ".tar" or ".so" are called filename suffices, which is a different thing from a filename extension. Whereas a suffix is part of the filename string stored in the underlying filesystem's metadata (inode for the most of them), an extension is a separate metadata string, i.e. extension does not consume any portion of the actual filename string and thus does not decrease the maximum filename length.

Most filesystems (e.g. UFS, VxFS, ZFS, XFS) don't have extensions, therefore the ".png" part of a filename like "picture.png" in those filesystems is not an extension and may not be called that, it's just a suffix. A few filesystems though, mostly of Microsoft/IBM/DEC origin (e.g. FAT and NTFS), do have extensions--for them a suffix is also an extension. All in all, an extension is a subset of the suffix term--a specialized (non-common) representation of a suffix hardcoded into the filesystem as a dedicated metadata field. This distinction is important, therefore I propose the article to be renamed to "Filename suffix" and a separate article "Filename extension" be created to detail those select filesystem cases where suffix is made into a separate metadata entry.

Cheers. (talk) 15:27, 23 October 2014 (UTC)

Well, this article definitely covers both cases, and for most purposes I guess the distinction is transparent, explaining why there is only one article.–Jérôme (talk) 19:03, 9 April 2016 (UTC)

leadin {{NPOV}}[edit]

The leading is unnecessarily restrictive. Some systems have extensions that are not separated by space or dos but instead rely on other syntax, e.g., parentheses. I twice attempted to correct it with the text

A filename extension is an identifier specified as a suffix to the name or (separated from the base filename by, e.g., a dot, a space), that indicates, e.g, the encoding (file format) , the usage, of a computer file. Examples of filename extensions are .png, .jpeg, .exe and .dmg,.txt. Note that some systems might have multiple types of extension, e.g., in CMS CMS EXEC A1 has two extensions, the filetype EXEC and the filemode[a] A1.

but User:J._M. twice reverted it. He claims that it does not make sense and that thee wa a broken link, but it says almost the same thing as the original sentence and the footnote that I added was resolved with:

== Notes ==


  1. ^ Roughly a combination of drive letter and mount attributes.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:28, 3 August 2015 (UTC)

The primary problem with your edit is its poor quality. And, I don't mean to offend you, but looking at your comment here, I think you could seriously benefit from someone proofreading your edits. Generally, when someone repeatedly points out that your edit is broken, I recommend re-reading it first.
Now, for your version:
"an identifier specified as a suffix to the name or (separated from the base filename by, e.g., a dot, a space)"
Or what? A word is missing. The sentence is broken. Furthermore, the original sentence was straightforward and easy to read. This new version with its extra commas (and a redundant space before one of them) is quite convoluted, difficult to make head or tail of, without adding extra information (you say it says almost the same thing as the original one). So I can't see how this could be an improvement.
For the broken link, I meant CMS, which leads to a disambiguation page with 60+ items. How is the reader supposed to know which CMS it is?
As for the multiple types of extension, I am not against mentioning them. My concern was that "The lead section should briefly summarize the most important points covered in an article … Editors should avoid lengthy paragraphs and over-specific descriptions, since greater detail is saved for the body of the article." I just didn't think the introduction should explain these (in my opinion) rather exotic details, they can be mentioned anywhere else in the article. I don't think the current intro implies there can be only one type of extension.—J. M. (talk) 19:27, 3 August 2015 (UTC)
A link to a disambiguation page is not a broken link.
How about:
A filename extension is an identifier specified as a suffix to the name by syntax, often separated from the base filename (by, e.g., a dot, a space), that indicates, e.g, the encoding (file format) , the usage, of a computer file. Examples of filename extensions are .png, .jpeg, .exe, .dmg, and .txt. Note that some systems might have multiple types of extension, e.g., in CMS CMS EXEC A1 has two extensions, the filetype EXEC and the filemode[a] A1.
== Notes ==
Alternatively how about condensing the leadin and moving the DOS-specific text to Filename extension#Usage
  1. ^ Roughly a combination of drive letter and mount attributes.
This one is OK with me. There's still the redundant space in "(file format) , the usage" and the missing dot in e.g. ("that indicates, e.g"). But I think this version is better.—J. M. (talk) 01:43, 5 August 2015 (UTC)

(ALAR) text messes up formatting[edit]

After the <h1></h1>, in #re:My Page , subsequent header lines are treated as subordinate to it. Is the (ALAR) material spam that can be deleted, or does the markup need to be fixed? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:40, 3 August 2015 (UTC)

Probably spam. I deleted it.—J. M. (talk) 21:39, 3 August 2015 (UTC)