Talk:Filename extension

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Filename extension article.
Article policies
This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
B This article has been rated as B-Class on the quality scale
Mid This article has been rated as Mid-importance on the importance scale

Contents

[edit] Untitled document 1

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

[edit] Untitled document 2

viewed by Aamir Hanif

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

RISC OS doesn't use filename extentions at all.

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

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

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

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

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

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

[edit] 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.

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

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