View source for Talk:Filename extension

{{talkheader}}
{{WikiProject banner shell|class=Start|vital=yes|1=
{{WikiProject Computing|importance=Mid|image-needed=yes}}
}}
== Windows 3.x an operating system?/NTFS not 8.3?/interpreter directives ==
# 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.
# 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?

[[User:Tannin|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
<blockquote>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).
</blockquote>
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.

[[User:Iain.dalton|Iain Dalton]] ([[User talk: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 [[Microsoft Windows|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. [[User:Guy Harris|Guy Harris]] ([[User talk: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.
- [[User:Kim Bruning|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: <tt>file</tt> 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". <tt>make</tt>, 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.

::<code>man file</code>
  "... 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 link]]s, empty files, etc] and ''[[magic number (programming)|magic number]]'' tests) 

::<code>info make</code>
 "...   "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. ..."

::- [[User:IMSoP|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 [[Compatible Time-Sharing System|CTSS]] and [[Conversational Monitor System|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.   [[Digital Equipment Corporation|DEC]] operating systems such as [[TOPS-10]], various [[PDP-11]] operating systems, and [[OpenVMS|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. [[User:Guy Harris|Guy Harris]] 00:52, 29 March 2006 (UTC)

Thank you very much. [[User:Tattoeko|Tattoeko]] ([[User talk: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, [[sandbox]]ing). Most programs already provide such protection (notably [[Eudora (email client)|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.

[[User:Kim Bruning|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. -- [[User:TakuyaMurata|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.
[[User:Hhhobbit|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. [http://arstechnica.com/reviews/os/macosx-10.1.ars/12] [http://arstechnica.com/reviews/os/macosx-10.4.ars/6] (And Apple's in-progress move to [[Universal Type Identifier]]s, but I digress.) [[User:Alerante|æle]]&nbsp;<small>[[User talk:Alerante|✆]]&nbsp;'''2006-03-28'''''t'''''02:30'''''z''</small>

:That's [http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html#//apple_ref/doc/uid/TP40001319-CH201-DontLinkElementID_19 Uniform Type Identifiers]. [[User:Guy Harris|Guy Harris]] 21:57, 29 July 2006 (UTC)

== Is the dot part of the extension? ==

Is the dot part of the extension or not? [[User:Softreviewer|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. [[User:Guy Harris|Guy Harris]] 02:00, 2 June 2006 (UTC)

:: Thank you. [[User:Softreviewer|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://en.wikipedia.org/w/index.php?title=Filename_extension&oldid=53240996
[[User:Andy Christ|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. [[User:Guy Harris|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. [[User:Nneonneo|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? -[[User:Rushyo|<span style="color: #FF00FF;">'''Rushyo'''</span>]] [[User_talk:Rushyo|<span style="color: #990099; font-size: 0.8em;"><sup>Talk</sup></span>]] 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. --[[User:Keith111|Keith111]] ([[User talk: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) --[[User:Nigelj|Nigelj]] ([[User talk:Nigelj|talk]]) 19:51, 31 May 2009 (UTC)

<blockquote>
Hello,

I've just noticed [http://en.wikipedia.org/w/index.php?title=Filename_extension&diff=293562274&oldid=293484333 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, [[User:Oli Filth|Oli Filth]]<sup>([[User talk:Oli Filth|talk]]<nowiki>|</nowiki>[[Special:Contributions/Oli_Filth|contribs]])</sup> 19:09, 31 May 2009 (UTC)
</blockquote>

Hi Oli,

I haven't worked in Java for some years, but there are several points I can make:
#It's very hard to prove a negative.  
#The tutorial lists only MS Windows versions from W2K onwards (all long-filename-compatible)
#It says "Be Careful When You Type: Type all code, commands, and file names exactly as shown."
#With my current javac on this machine, if I name the file 'HelloWorldApp.jav' or 'HelloWorldApp.txt', it will not compile.
#In the list of options available for the javac program, none mentions allowing other filename extensions
#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'
#I remember all this being true when I first started messing with javac on Win95 and Win98 machines
#In those days there was no other way to compile java code besides the Sun-supplied javac program
#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

--[[User:Nigelj|Nigelj]] ([[User talk: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.  [[User:Oli Filth|Oli Filth]]<sup>([[User talk:Oli Filth|talk]]<nowiki>|</nowiki>[[Special:Contributions/Oli_Filth|contribs]])</sup> 20:14, 31 May 2009 (UTC)

:: Well found, Oli. [http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html] is much better than the ref I provided. --[[User:Nigelj|Nigelj]] ([[User talk:Nigelj|talk]]) 14:30, 3 June 2009 (UTC)

== .dwg extension trademarked? ==
# 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? [[User:Donk10k|The Donc]] ([[User talk:Donk10k|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.  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/95.220.149.228|95.220.149.228]] ([[User talk:95.220.149.228|talk]]) 07:18, 27 February 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== 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
[[Special:Contributions/74.240.61.242|74.240.61.242]] ([[User talk: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.  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/99.224.181.247|99.224.181.247]] ([[User talk:99.224.181.247|talk]]) 05:06, 7 May 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

  Rimmysingh</h1rimmysingh/h>  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/14.98.21.104|14.98.21.104]] ([[User talk:14.98.21.104|talk]]) 09:48, 25 November 2011 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== 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. [[Special:Contributions/82.75.155.228|82.75.155.228]] ([[User talk: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. [[Special:Contributions/176.195.85.75|176.195.85.75]] ([[User talk: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.–[[User:Jérôme|Jérôme]] ([[User talk: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. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 11:40, 11 November 2023 (UTC)

== leadin {{tl|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 [[substring|suffix]] to the [[filename|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 <code>.png</code>, <code>.jpeg</code>, <code>.exe</code> and <code>.dmg</code>,<code>.txt</code>. Note that some systems might have multiple types of extension, e.g., in [[CMS]] <code>CMS EXEC A1</code> has two extensions, the filetype '''EXEC''' and the filemode{{efn|Roughly a combination of drive letter and mount attributes.}} '''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:

<nowiki>== Notes ==</nowiki>

<nowiki>{{Notelist}} </nowiki>

{{Notelist}}

[[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk: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 [[substring|suffix]] to '''the [[filename|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 ''"[[Wikipedia:Manual of Style/Lead section|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.—[[User:J. M.|J. M.]] ([[User talk: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 [[substring|suffix]] to the [[filename|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 <code>.png</code>, <code>.jpeg</code>, <code>.exe</code>, <code>.dmg</code>, and <code>.txt</code>. Note that some systems might have multiple types of extension, e.g., in [[Conversational Monitor System|CMS]] <code>CMS EXEC A1</code> has two extensions, the filetype '''EXEC''' and the filemode{{efn|Roughly a combination of drive letter and mount attributes.}} '''A1'''.

:::<nowiki>== Notes ==</nowiki>

:::<nowiki>{{Notelist}} </nowiki>

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

::{{Notelist}}

:::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.&mdash;[[User:J. M.|J. M.]] ([[User talk:J. M.|talk]]) 01:43, 5 August 2015 (UTC)

== (ALAR) text messes up formatting ==

After the <nowiki><h1></h1>,</nowiki> 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? [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk:Chatul|talk]]) 18:40, 3 August 2015 (UTC)

:Probably spam. I deleted it.&mdash;[[User:J. M.|J. M.]] ([[User talk: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 <b style="background: Black;color:Gold;">&nbsp;tav&nbsp; </b> 12:53, 18 January 2017 (UTC)

:If you rewrite it, keep shell scripts in mind, which typically begin with a ''shebang'' ('''#!'''). [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk: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.) [[User:Guy Harris|Guy Harris]] ([[User talk: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. [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk: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 [[Time Sharing Option|TSO]] as a file type was inspired by [[Multics]]? [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk:Chatul|talk]]) 15:11, 14 August 2018 (UTC)

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

{{Ping|‎Daniel.Cardenas}}The article makes the overly broad claim that the extionsion is separated by a period. In [[CP-67]] and [[VM (operating system)|VM]] it is separated by a space. I corrected that once and [[user:Daniel.Cardenas]] removed my correction with the comment {{tq|Deleted text without a citation: , but in some systems it is separated with spaces}}. I reverted the deletion and added<ref>{{cite manual
 |     title = z/VM Version 7 Release 1 CMS Primer
 |        id = SC24-6265-00
 |   section = What Is a File?
 |      page = 7
 | quote = One thing you need to know about creating files with z/VM is that each file needs its own three-part identifier. The first part of the identifier is the file name. The second part is the file type. And the third part is the file mode. These three file identifiers are often abbreviated fn ft fm. 
 |      date = 2018-09-11
 |       url = https://www-01.ibm.com/servers/resourcelink/svc0302a.nsf/pages/zVMV7R1sc246265/$file/dmsb2_v7r1.pdf
 | publisher = IBM
 }}
</ref> a citation, and he reverted it with no{{efn|The comment {{tq|see wp:cite - ... it is likely to be removed from the article}} doesn't explain anything, because I '''did''' provide a reliable source for the challenged material.}} explanation. [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk:Chatul|talk]]) 23:47, 23 June 2020 (UTC)
:Your revert cited a different reason: that is what {{tl|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. [[User:Daniel.Cardenas|Daniel.Cardenas]] ([[User talk: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. --[[Special:Contributions/83.137.6.235|83.137.6.235]] ([[User talk: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 ([[Compatible Time-Sharing System|CTSS]], [[Conversational Monitor System|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.) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 03:09, 24 June 2020 (UTC)

{{Notelist-talk}}

{{Reflist-talk}}

== 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'? [[User:Laufantilope|Laufantilope]] ([[User talk: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 [[CP-67|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. [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk: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 [http://www.bitsavers.org/pdf/dec/pdp6/DEC-6-0-EX-SYS-UM-FP_ACT00_PDP-6_Multiprogramming_System_Manual_Apr66.pdf 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, [[Compatible Time-Sharing System|CTSS]] predated "TOPS-6", as well as CMS and Multics.  [http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf 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. [[User:Guy Harris|Guy Harris]] ([[User talk: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.
[[User:HappyMouse2|HappyMouse2]] ([[User talk: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. [[User:Siodhe|Alex North-Keys]] ([[User talk:Siodhe|talk]]) 04:49, 23 November 2024 (UTC)