Talk:Filename extension

Windows 3.x an operating system?/NTFS not 8.3?/interpreter directives

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)

Multiple topics in the same thread, due to multiple topics in individual comments. I've put the thread into a section of its own, with a title mentioning all three topics.

For the first topic, that section currently says "In DOS and 16-bit Windows, file names have a maximum of 8 characters, a period, and an extension of up to three letters.", which avoids the term "operating system" entirely.

For the second topic, the bit about the patch and the three-character limitation is no longer in the article. There is no 3-character limitation on file extensions on VFAT and FAT32 file systems, when accessed from 32-bit and 64-bit applications. (16-bit applications still have that limitation in the API, as far as I know.)

For the third topic, "the above" have been put into this section, which I gave a name that reflects most of the topics in this thread.

For the fourth topic, a #! line isn't like a degenerate resource fork or extended attribute, it's part of the file data. I've removed that parenthetical comment. Guy Harris (talk) 22:52, 18 September 2024 (UTC)

Filename extensions are a DOS-ism?

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, where a file name was an arbitrary string at the file system API layer, but where there were 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)

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

responsibilities of email programs

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)

Clean

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

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?

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

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.

contradiction?

"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://wiki.riteme.site/w/index.php?title=Filename_extension&oldid=53240996 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

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

"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

(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)

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)

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)

.dwg extension trademarked?

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)

Incorrect meaning

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)

re:My Page

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)

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

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

Contradiction

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)

Suffix, not extension!

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)

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)

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/ReFS file system on Windows. Guy Harris (talk) 11:40, 11 November 2023 (UTC)

leadin {{NPOV}}

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

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

(ALAR) text messes up formatting

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)

Unix Executables

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

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)

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)

Use of LLQ in TSO?

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)

WP:NPOV The extension is not always separated by a period

@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 a citation, and he reverted it with no explanation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:47, 23 June 2020 (UTC)

Your revert cited a different reason: that is what {{cn}} is for. Which is a non excuse. I reverted and explained that 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)

This article should be rewritten from scratch. Thie filename extension looks like a VAX/VMS feature. Its filesystem (Files-11) specifies the "file-type" attribute of up to 38 characters, although most of the default file types have only 3 characters. The file-type must be preceded by a period: node::device:[directory]filename.file-type;version. Since the days of Unix (System V and especially POSIX.1) filenames can contain any character except the directory separator and null character, and there is no explicit filetype extension attribute. --83.137.6.235 (talk) 01:17, 24 June 2020 (UTC)

This article describes filename extensions on multiple operating systems. It speaks of systems where the extension is separate from the name (CTSS, CMS, various DEC operating systems including but not limited to VMS,CP/M, MS-DOS, etc.) and systems where the file name is a string in which "." isn't a special character and, by convention, file names can end with a separator such as a "." followed by an extension (Multics, Unix and Unix-like systems, OS/2 when not using the FAT file system, Windows 9x, Windows NT). It also discusses the behavior of code above the file system, using the extension to indicate how to process the file. So, no, it doesn't solely discuss systems where the file name is a string in which "." isn't a special character, but that's not a bug, that's a feature; it does discuss them, just as it discusses systems where the extension is separate from the name. (I.e., this is not an article about UN*X file names, it's an article about file extensions on many different operating systems.) Guy Harris (talk) 03:09, 24 June 2020 (UTC)

Notes

References

What's the right term for this?

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)

Where did the notion of filename extensions originate?

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.

Multics treated a period as just another character and adopted the convention of naming source segments with the language following the last period. 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)

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)

Proposed move to File Extension.

I would like to move this page to "file extension". The shorter title is more natural and not ambiguous. It is also the more common name used. Also, delete the redirect at file extension because it has edit history and I cannot move the page myself. HappyMouse2 (talk) 17:07, 8 June 2021 (UTC)

"filename extension" (or "filename suffix") is decidedly more specific than "file extension", which could potentially describe a file content extension of some kind. Since this isn't what you meant, that last term seems ambiguous. Alex North-Keys (talk) 04:49, 23 November 2024 (UTC)