Talk:Filename extension

From Wikipedia, the free encyclopedia

Bold text1: 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

---

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)

---

Contents 1 responsibilities of email programs 2 Clean 3 File extensions in Mac OS X 4 Is the dot part of the extension?

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

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

               KANNIH NIH A MIN AH KIWI KAN TI NAK HI KAN KHUA KAN RAM PAWL MINUNG HI KIWI AN NI TI I KAN
               MAH I VAKOK KA NI TI BAN TUK KHIN SAWH MI AN NGEI VE RUANG AH A SI