5 ms·

First, the 3-character file extension predates CP/M. It goes at least as far back as various DEC operating systems like RT-11 and RSTS/E; probably there are an

First, the 3-character file extension predates CP/M. It goes at least as far back as various DEC operating systems like RT-11 and RSTS/E; probably there are antecedents further back in time. I've also seen old filesystems with 2-character extensions, but 3 has been common for quite some time. I think that the original selection of 3 character extensions was made because it felt like a comfortable number of characters to make something meaningful while not being too burdensome to type. The fact that we still tend towards <= 3 character extensions is probably because this is still true, not because of a conscious attempt to maintain DOS compatibility.

Alupis 12y ago
I've only ever seen Windows-based systems adhere strictly to the 3-character extension. All 'Nix's I've worked with (Linux, BSD's, etc) usually have native files on the system with extensions longer than 3 characters. (.conf anyone?) Also, probably should note, file extensions are largely a Windows-based OS thing as well. On the 'Nix's, an extension isn't really needed (OK, it's not needed on Windows-based OS's either, but the OS prefers it). the "file" command will tell you all you need to know about a file without an extension. Or, you can just open it with a text editor. Or, execute it if it has execute permissions, etc. So, it seems, the 3-character extension (or extensions at all) are really a Windows-Based OS thing. (While we're at it, Windows-Based OS's are the only OS's I've worked with that actually require something in-front of the "."! For example, try to natively create a ".somefile" on Windows -- it will complain and not let you).
- ppog 12y ago
  Windows has allowed extensions longer than 3 characters for about 20 years now. I'm not sure what you mean by "natively create" but it also definitely doesn't require anything before the "." -- e.g. I have files called ".gitignore" etc. just as on any other OS.
  - dahdum 12y ago
    Right click a text file (such as "example.txt") and try to rename to ".gitignore". You get an error popup dialog "Rename: You must type a file name." That's what he means...you can create it in various applications though.
    - lucb1e 12y ago
      That is the most annoying error ever. No, I must not! I shall decide for myself what I must and mustn't do! /me opens cmd.exe and uses ren untitled.txt .gitignore A slightly bigger challenge is a file named CON :)
      - nik41tkins 12y ago
        Or .... , but that one is fairly easy as long as you COPY from the CONsole to a <fileName>. And remember ^Z to save and quit.
- bodyfour 12y ago
  Yes, UNIX's never had a concept of a limited length file extension. Until the 1980s filenames were limited to 14 characters in total, but you could put a dot anywhere you like in it. I was specifically referring to the part of the article that the author claimed that windows inherited it from MS-DOS, which inherited it from CP/M. The chain goes back farther than that -- by the time CP/M was written the 3-character file extension was well-established. In general CP/M was influenced a lot by the DEC minicomputer OSes (its "PIP" command is one obvious example)
  - rakoo 12y ago
    > UNIX's never had a concept of a limited length file extension AFAICT, UNIX never had a concept of file extensions.
    - bodyfour 12y ago
      At the filesystem layer? No, never. However even in the earliest of days file extensions were common. They followed the usual UNIX preference for brevity: ".c", ".h", ".o", and ".a" were all early arrivals. So even though they didn't cram extensions into the filesystem, they weren't allergic to it as a convention. In the 80s you started seeing things like "resolv.conf" appear, so they didn't stay mostly-single-character for long.
- daemin 12y ago
  In Windows Explorer it will complain if you try and create a file starting with a dot, but I suspect that it's because extensions are hidden by default, so you'd end up creating a file with no name. Can easily create such files by other means (saving in notepad, sublime, etc).
  - tokenizerrr 12y ago
    There's a trick. You can for example name a file .gitignore. (with a starting and trailing dot), it will warn you about changing the extension which you agree to, and you're left with a file named .gitignore
finin 12y ago
I recall DEC's TOPS10 operating system for the PDP-10 using three character extensions. It was introduced in 1970. I think the older PDP6 and ITS systems at MIT-AI had a different scheme for extensions. On ITS I recall that a file had a name and a version number and you could get the most recent version of the file named FOO by referring to it as "FOO >". Every time you edited FOO, you created a new version whose extension was incremented by one. Periodically you issued a command that deleted all of the old versions. IIRC I first saw the three-letter extension scheme when I started using TOPS10 in 1974.
lucb1e 12y ago
> while not being too burdensome to type Exactly, and nowadays we have fast enough storage that reading the first few bytes of a file isn't a burden either. Might as well do that instead of appending bytes to each filename. Magic mime is more reliable, versatile and arguably safer (.jpg.exe attachments..?).
- DougWebb 12y ago
  If I'm bringing up a directory listing, and the GUI tool I'm using is showing me different icons for different file types (or some other type-specific visual distinction), then I don't want it to have to read the first few bytes of every file in the directory. That doesn't scale. The file type needs to be part of the directory listing itself. Traditionally on Windows it's been part of the filename (which typically is only part of the directory listing, and not attached to the file) but it could have been stored as an attribute as well. That would have made more sense, but even NTFS was designed at a time when disk space actually cost something, and a filetype attribute probably would have wound up being a GUID registry key, which is a lot of bytes for every file in a big directory.
  - lucb1e 12y ago
    Fair point, and as you mention it could be optimized by using an attribute for magic mime cache. Another optimization is showing only the icons for the files currently in view, which should scale pretty much forever (I can't imagine so many files being in view that this becomes impractical without the view itself being useless). File managers already do this for thumbnails, though that's because they need to read the entire (often megabytes large) image.
- bodyfour 12y ago
  I wonder if it's really safer. You'd probably find that you'd have different magic databases and a carefully constructed (malicious) document might give different answers. Imagine that your email client decided a document was a PDF, but your file manager thought it was a loadable extension. You're trading one class of vulnerability for another. I'd also argue that the endurance of the file extension is a hint that people may actually like them. Extensions were invented as an affordance to the computer (which it no longer needs) but the information they convey is useful to humans as well. It may be a quirky old convention, but it provides a universally-understood language for describing a file type. Anyway, I think the overall discussion on this submission is a good example of why 3-character extensions survive: some people here argue for longer extensions, others say we should have no extensions, and the silent majority is happy to keep splitting the difference.

Alupis 12y ago

I've only ever seen Windows-based systems adhere strictly to the 3-character extension. All 'Nix's I've worked with (Linux, BSD's, etc) usually have native files on the system with extensions longer than 3 characters. (.conf anyone?) Also, probably should note, file extensions are largely a Windows-based OS thing as well. On the 'Nix's, an extension isn't really needed (OK, it's not needed on Windows-based OS's either, but the OS prefers it). the "file" command will tell you all you need to know about a file without an extension. Or, you can just open it with a text editor. Or, execute it if it has execute permissions, etc. So, it seems, the 3-character extension (or extensions at all) are really a Windows-Based OS thing. (While we're at it, Windows-Based OS's are the only OS's I've worked with that actually require something in-front of the "."! For example, try to natively create a ".somefile" on Windows -- it will complain and not let you).

ppog 12y ago
Windows has allowed extensions longer than 3 characters for about 20 years now. I'm not sure what you mean by "natively create" but it also definitely doesn't require anything before the "." -- e.g. I have files called ".gitignore" etc. just as on any other OS.
- dahdum 12y ago
  Right click a text file (such as "example.txt") and try to rename to ".gitignore". You get an error popup dialog "Rename: You must type a file name." That's what he means...you can create it in various applications though.
  - lucb1e 12y ago
    That is the most annoying error ever. No, I must not! I shall decide for myself what I must and mustn't do! /me opens cmd.exe and uses ren untitled.txt .gitignore A slightly bigger challenge is a file named CON :)
    - nik41tkins 12y ago
      Or .... , but that one is fairly easy as long as you COPY from the CONsole to a <fileName>. And remember ^Z to save and quit.
bodyfour 12y ago
Yes, UNIX's never had a concept of a limited length file extension. Until the 1980s filenames were limited to 14 characters in total, but you could put a dot anywhere you like in it. I was specifically referring to the part of the article that the author claimed that windows inherited it from MS-DOS, which inherited it from CP/M. The chain goes back farther than that -- by the time CP/M was written the 3-character file extension was well-established. In general CP/M was influenced a lot by the DEC minicomputer OSes (its "PIP" command is one obvious example)
- rakoo 12y ago
  > UNIX's never had a concept of a limited length file extension AFAICT, UNIX never had a concept of file extensions.
  - bodyfour 12y ago
    At the filesystem layer? No, never. However even in the earliest of days file extensions were common. They followed the usual UNIX preference for brevity: ".c", ".h", ".o", and ".a" were all early arrivals. So even though they didn't cram extensions into the filesystem, they weren't allergic to it as a convention. In the 80s you started seeing things like "resolv.conf" appear, so they didn't stay mostly-single-character for long.
daemin 12y ago
In Windows Explorer it will complain if you try and create a file starting with a dot, but I suspect that it's because extensions are hidden by default, so you'd end up creating a file with no name. Can easily create such files by other means (saving in notepad, sublime, etc).
- tokenizerrr 12y ago
  There's a trick. You can for example name a file .gitignore. (with a starting and trailing dot), it will warn you about changing the extension which you agree to, and you're left with a file named .gitignore

finin 12y ago

I recall DEC's TOPS10 operating system for the PDP-10 using three character extensions. It was introduced in 1970. I think the older PDP6 and ITS systems at MIT-AI had a different scheme for extensions. On ITS I recall that a file had a name and a version number and you could get the most recent version of the file named FOO by referring to it as "FOO >". Every time you edited FOO, you created a new version whose extension was incremented by one. Periodically you issued a command that deleted all of the old versions. IIRC I first saw the three-letter extension scheme when I started using TOPS10 in 1974.

lucb1e 12y ago

> while not being too burdensome to type Exactly, and nowadays we have fast enough storage that reading the first few bytes of a file isn't a burden either. Might as well do that instead of appending bytes to each filename. Magic mime is more reliable, versatile and arguably safer (.jpg.exe attachments..?).

DougWebb 12y ago
If I'm bringing up a directory listing, and the GUI tool I'm using is showing me different icons for different file types (or some other type-specific visual distinction), then I don't want it to have to read the first few bytes of every file in the directory. That doesn't scale. The file type needs to be part of the directory listing itself. Traditionally on Windows it's been part of the filename (which typically is only part of the directory listing, and not attached to the file) but it could have been stored as an attribute as well. That would have made more sense, but even NTFS was designed at a time when disk space actually cost something, and a filetype attribute probably would have wound up being a GUID registry key, which is a lot of bytes for every file in a big directory.
- lucb1e 12y ago
  Fair point, and as you mention it could be optimized by using an attribute for magic mime cache. Another optimization is showing only the icons for the files currently in view, which should scale pretty much forever (I can't imagine so many files being in view that this becomes impractical without the view itself being useless). File managers already do this for thumbnails, though that's because they need to read the entire (often megabytes large) image.
bodyfour 12y ago
I wonder if it's really safer. You'd probably find that you'd have different magic databases and a carefully constructed (malicious) document might give different answers. Imagine that your email client decided a document was a PDF, but your file manager thought it was a loadable extension. You're trading one class of vulnerability for another. I'd also argue that the endurance of the file extension is a hint that people may actually like them. Extensions were invented as an affordance to the computer (which it no longer needs) but the information they convey is useful to humans as well. It may be a quirky old convention, but it provides a universally-understood language for describing a file type. Anyway, I think the overall discussion on this submission is a good example of why 3-character extensions survive: some people here argue for longer extensions, others say we should have no extensions, and the silent majority is happy to keep splitting the difference.