Talk:Filename extension

This  level-5 vital article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing Mid‑importance 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Mid This article has been rated as Mid-importance on the project's importance scale. An editor has requested that an image or photograph be added to this article.

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)[reply]

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)[reply]

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)[reply]

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

Guy Harris 00:52, 29 March 2006 (UTC)[reply

]

Thank you very much. Tattoeko (talk) 20:45, 13 August 2018 (UTC)[reply]

Please clarify: is the correct naming 'file name extension' or 'file extension'? Which spelling is the correct one: 'filename' or 'file name'? Laufantilope (talk) 09:29, 30 September 2019 (UTC)[reply]

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

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)[reply]

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

That's Uniform Type Identifiers.

Guy Harris 21:57, 29 July 2006 (UTC)[reply

]

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

"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)[reply

]

Thank you. Softreviewer 17:39, 2 June 2006 (UTC)[reply]

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. http://en.wikipedia.org/w/index.php?title=Filename_extension&oldid=53240996 Andy Christ 18:56, 27 June 2007 (UTC)[reply]

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)[reply

]

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

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)[reply]

(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)[reply]

Hello,

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 (83.253.140.181) 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)[reply]

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)[reply

]

Well found, Oli. [3] is much better than the ref I provided. --Nigelj (talk) 14:30, 3 June 2009 (UTC)[reply]

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 95.220.149.228 (talk) 07:18, 27 February 2011 (UTC)[reply]

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 74.240.61.242 (talk) 19:54, 24 April 2011 (UTC)[reply]

"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 99.224.181.247 (talk) 05:06, 7 May 2011 (UTC)[reply]

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

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. 82.75.155.228 (talk) 14:26, 3 March 2014 (UTC)[reply]

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. 176.195.85.75 (talk) 15:27, 23 October 2014 (UTC)[reply]

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)[reply]

NTFS doesn't have extensions, it just has a file name that's a string, although some layer of NT may prevent files with "." as the last character of the name from being created.

VFAT

doesn't have extensions, either, just a string, albeit one stored in a somewhat hackish fashion.

An "extension" is anything that's stored at the end of the file name following a ".", or along with the rest of the file name, and that is used to indicate a file type, so, for example, a file named "hello.c" with the "Hello, World!" program's C source in it has ".c" as the extension of the file name, regardless of whether it's "HELLO.C" in a non-VFAT FAT (case-insensitive and non-case-preserving) file system on DOS or Windows, or "hello.c" in a UN*X file system or a VFAT/NTFS/

Guy Harris (talk) 11:40, 11 November 2023 (UTC)[reply

]

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 ==

{{Notelist}}

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

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)[reply]

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 ==

{{Notelist}}

Alternatively how about condensing the leadin and moving the DOS-specific text to Filename extension#Usage

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)[reply]

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)[reply]

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

"Usage: Executable files do not have a standard extension; a magic number at the beginning of the file indicates whether it's executable"

I believe this is only partially correct and serves to confuse the matter because in practise a file is executable according to its permission while a magic number can identify a binary file as executable but it may not be executable on the current platform (i.e. it is targeted at Arm rather than Solaris, for example). Binary executables for ELF (.elf), COFF (.bin) & a.out (.out) all contain extensive header information not just a magic number  tav  12:53, 18 January 2017 (UTC)

If you rewrite it, keep shell scripts in mind, which typically begin with a shebang (#!). Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:58, 18 January 2017 (UTC)[reply]

And bear in mind that "shell scripts" really means "scripts", as that can be used by any scripting language processor that won't get confused by the first line being "#! {pathname}" (either because "#" is a comment character in the language or because it special-cases shebang lines).

(Also note that 1) "Arm" and "Solaris" are not alternatives - ARM and SPARC and x86 and... are alternatives, and Linux and Solaris and... are alternatives, but at least at one point in the history of OpenSolaris, there was a Solaris-on-ARM project and 2) there's also Mach-O, which also has a header with a magic number and other information.)

(The "Executable files do not have a standard extension" part, of course, is 100% correct.)

Guy Harris (talk) 20:10, 18 January 2017 (UTC)[reply

]

As a side note, Multics is simiar to Unix in that execute permission controls whether a segment is executable, not the name. I don't recall whether Multics had a naming convention for scripts. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:17, 14 August 2018 (UTC)[reply]

Does anybody know whether IBM's use of the low level qualifier (LLQ) in TSO as a file type was inspired by Multics? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:11, 14 August 2018 (UTC)[reply]

@Daniel.Cardenas:The article makes the overly broad claim that the extionsion is separated by a period. In CP-67 and VM it is separated by a space. I corrected that once and user:Daniel.Cardenas removed my correction with the comment Deleted text without a citation: , but in some systems it is separated with spaces. I reverted the deletion and added^[1] a citation, and he reverted it with no^[a] explanation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:47, 23 June 2020 (UTC)[reply]

Your revert cited a different reason: that is what {{

wp:cite says uncited sources can be removed at anytime. If you don't want your edits reverted, then don't use non excuses in your update summary. Daniel.Cardenas (talk) 00:14, 24 June 2020 (UTC)[reply

]

This article should be rewritten from scratch. Thie filename extension looks like a

directory separator and null character, and there is no explicit filetype extension attribute. --83.137.6.235 (talk) 01:17, 24 June 2020 (UTC)[reply

]

This article describes filename extensions on multiple operating systems. It speaks of systems where the extension is separate from the name (

Guy Harris (talk) 03:09, 24 June 2020 (UTC)[reply

]

So I came to this article looking for one particular datum, and was disappointed not to find it: What is the *origin* of filename extensions? I know I worked on old DEC operating systems (RSTS, TOPS-10) which had them, and had them baked into the filesystem. For example, the PDP-10 had a 36 bit word, and had a limited character code called 6 bit, where only upper case letters and digits and maybe a little bit more were supported, which allowed them to fit the character into 6 bits, which allowed you to pack six of them in the 36 bit word. So a filename was defined as one word (six 6 bit characters) for the filename proper, and one half-word (three 6 bit characters) for the extension (I think the other half of the word held protection flags or something). RSTS on the PDP-11 used RADIX-50 in a similar manner to get a hard-coded 6+3 filename in a limited character code.

What I *don't* know is if DEC originated this business of filename extensions or if they stole the idea from somewhere else. Perhaps IBM had it first? Perhaps IBM also had it but they too stole it from somewhere? It was obviously an extremely influential idea, given that we're still using extensions today, even when the filesystem doesn't require it; I'm curious to know where it came from.

Cambridge Monitor System (CMS) on Control Program-67 (CP-67) used an eight character file name and an eight character file type, separated by spaces; both came before the PDP-11. I don't guaranty that they were the first. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:04, 25 May 2021 (UTC)[reply

]

The PDP-11 isn't interesting in the history of file name extensions - DEC's operating systems for it probably got their notions of file name extensions from PDP-10 operating systems. And TOPS-10 version was originally the "PDP-6 Multiprogramming Monitor", which according to page 4-10 of the PDP-6 Multiprogramming System Manual, had the same 6.3 file name format.

The PDP-6 came out in 1964; the PDP-10 came out in 1966.

However, CTSS predated "TOPS-6", as well as CMS and Multics. The Programmer's Guide from 1963 says that "Each of the user's files has two names; commonly the second name is descriptive of the type of file, as "FAP," "DATA," "BSS," etc.".

So extensions, in that sense, date back at least to CTSS. DEC may have been the originators of the "extension is separated from the name with a period" convention, adopted by Multics, Unix, DOS, and Windows.

Guy Harris (talk) 20:47, 25 May 2021 (UTC)[reply

]