31

In MS-DOS (and FAT16), you could only have 8.3 file names (like QUESTION.TXT) with only single-case letters and numbers (and a few symbols). The MS-DOS Editor also defaulted to 8.3 - typing edit questiontxt in MS-DOS 6.22 would edit QUESTION.TXT.

While everything used 8.3, were 9.2 names possible?

For example, instead of the example above (QUESTION.TXT), would QUESTIONT.XT be an allowed filename (although it would not be practical)?

Zackary
  • 605
  • 6
  • 14
  • 16
    You could fake it by displaying an 8.3 name as 9.2 but no other program would display the name this way. –  Jun 25 '18 at 22:28
  • 4
    if you had two files named question.txt and questiont.xt, which one would open if you use "edit questiontxt"? – htmlcoderexe Jun 28 '18 at 08:34
  • As I recall only vaguely, PKUNZIP 2.04g (maybe an earlier version?) could extract a long filename in MS-DOS 6.22 (possibly using the shell named 4DOS), and then it would show up in DIR. Of course, this violated specification. You couldn't use DEL on the filename (although using . worked alright-ish enough), and I would expect(/hope, for sensibility's sake) that CHECKDSK would remedy the violation (somehow, possibly by just deleting the violating file). Since so much DOS software was custom-written code, you could sometimes have non-standard situations be treated in inconsistent ways. – TOOGAM Jan 25 '23 at 09:35
  • @TOOGAM that is a 4DOS extension: its version of DIR and various other commands look for a DESCRIPT.ION file and display file descriptions (long file names) stored there. Since this relies on a regular file, it works with any archiver, but few programs can actually work with the descriptions. – Stephen Kitt Mar 07 '23 at 20:06
  • @StephenKitt I don't think so. I was well familiar with the hidden DESCRIPT.ION file (which is an 8.3 filename). I was familiar enough that I think I checked and COMMAND.COM showed the file too. This was too many years ago and trying to verify that would be too time consuming right now, so I realize I'm not proving much or displaying a lot of solid logic to back my point here, but I don't believe this was an issue with me not understanding the involvement of the DESCRIPT.ION file. (Even so, thank you for your feedback.) – TOOGAM Mar 07 '23 at 22:18
  • @TOOGAM apologies for jumping to conclusions, DESCRIPT.ION is the only way I’m aware of to get the behaviour you’re describing (which doesn’t mean there aren’t any others of course). I would be rather surprised if MS-DOS 6.22’s COMMAND.COM was able to display any kind of “long” file name! PKUNZIP got support for LFNs in version 2.50, when run under Windows 9x; but version 2.04g couldn’t even extract EA DATA. SF files while preserving their name (which is fine, those files weren’t supposed to be archived, but it illustrates PKUNZIP’s limitations). – Stephen Kitt Mar 08 '23 at 13:34
  • (Come to think of it, maybe it wasn't a 9.3 filename, but maybe it was an 8.4 filename. And might have actually been MS-DOS 5 or 6, not 6.22. But was pre-Win95, or at least before Win9x was ever on my computer.) – TOOGAM Mar 09 '23 at 21:27

3 Answers3

135

No. The FAT12/16/32 filesystems store the filename and extension together in a fixed-length 11 character field. The first 8 characters of this field is the filename and the last 3 is the extension. Trailing space characters in both the filename proper and its extension are ignored. The '.' character between the filename and extension is implicit. Additionally, the '.' character is not a valid character in either the filename or the extension. Spaces, however, are permitted. Note that the above does not apply to VFAT which is its own kettle of worms.

   on disk:          on screen:
┌───────────┐
│AUTOEXECBAT│  <=>  AUTOEXEC.BAT
│CONFIG  SYS│  <=>  CONFIG.SYS
└───────────┘
deltab
  • 103
  • 2
Alex Hajnal
  • 9,350
  • 4
  • 37
  • 55
  • 21
    "kettle of worms"? as opposed to "can of fish"? – Martin Smith Jun 26 '18 at 07:31
  • 17
    @MartinSmith Just my penchant for mangling English expressions: "Kettle of worms", "Not the sharpest pin in the cookie jar", etc. – Alex Hajnal Jun 26 '18 at 11:28
  • 8
    And using kettle of worms to describe VFAT is putting it mildly. If you want a fun evening, try repairing a broken VFAT filesystem with a hex editor. – Alex Hajnal Jun 26 '18 at 11:31
  • 18
    Even worse. I was once sent a data file someone had named COM_something_or_other. (For "Community".) DOS thought it was a COM port. IIRC I had go fiddle with a hex editor before anything useful could be done with it. But that's beating a dead horse of a different color. – MickeyfAgain_BeforeExitOfSO Jun 26 '18 at 13:23
  • One time I had a CD file with a ? in the filename - that was a REAL mess because I couldn't edit the directory. – manassehkatz-Moving 2 Codidact Jun 26 '18 at 14:44
  • 6
    I still like to pass files called something like this\is:a\file, to my friends that are still using Microsoft Windows. – ctrl-alt-delor Jun 26 '18 at 19:45
  • 1
    @ctrl-alt-delor It's not just Windows that's affected. I run into problems all the time transferring files with colons in their names from Linux (ext3, ext4) to Android and various embedded systems (all using VFAT filesystems). – Alex Hajnal Jun 26 '18 at 19:54
  • @AlexHajnal Because vfat is MS-dos. That is designed for MS_dos, so has all of the limitations. And Unix only limits / and null (that is the character that has the encoding of 00000000). – ctrl-alt-delor Jun 26 '18 at 20:04
  • @ctrl-alt-delor More like VFAT is Windows which inherited its filename restrictions from DOS. But yea, the limitations are from the originating OS. AFAIR, there's no technical reason one couldn't have e.g. colons in a VFAT (or FAT for that matter) filename; the standard simply bans those characters for compatibility reasons (much as *NIX does with / and NULL). – Alex Hajnal Jun 26 '18 at 20:09
  • I think nil (sorry I got it wrong first time), may be part of the implementation, but / is so that the OS can function. / is used as a separator. – ctrl-alt-delor Jun 26 '18 at 20:13
  • 1
    @ctrl-alt-delor Well, allowing NULL (nil, \0, ^@, it's all good) in a filename would break libc. e.g.: FILE fopen(const char path, const char *mode); – Alex Hajnal Jun 26 '18 at 20:15
  • 4
    @AlexHajnal Yes, but that is a C limitation, not a FAT one. The \0 is not used for anything special in FAT names. – tofro Jun 27 '18 at 07:10
  • Comments are not for extended discussion; this conversation has been moved to chat. – wizzwizz4 Jun 29 '18 at 16:04
28

No. The file extension is a first class concept in the DOS file systems, a legacy of CP/M, vs, say, Unix file systems where an extension is simply a naming convention.

Will Hartung
  • 12,276
  • 1
  • 27
  • 53
  • 9
    This doesn't explain why e.g. 7.4 FAT filenames weren't possible. – Alex Hajnal Jun 25 '18 at 23:07
  • 10
    @Alex The "legacy" defined it that way : at 8 characters on one side and 3 on the other side. So other combos were just not supported. – JB. Jun 26 '18 at 09:10
  • 2
    @AlexHajnal The answer implies that you cannot "abuse" one character of the extension for a longer base name because the separation is hard-coded into the file system, other than for file systems that see 8.3 file names just as a string of 12 characters. – mastov Jun 26 '18 at 09:50
  • @mastov the answer doesn’t imply any of that; all it says is that file extensions are a first class concept, it doesn’t say anything about how they’re stored or derived, not to mention anything about separation or file systems which see 8.3 file names as 12 characters. – Stephen Kitt Jun 26 '18 at 11:39
  • 1
    @mastov Of course one can display a string of characters any which way one chooses. The trouble with FAT is that it is closely tied to a ≤8.≤3 format. Unless one chooses to, say, always display filenames in a full 12-character 7.4 or 9.2 format it's non-trivial to decide how to format the string. You could, e.g. go with 11-character filenames (not 12) with an explicit '.' but that character is not permitted. So yes, displaying as 9.2 and that like is possible just not practical. – Alex Hajnal Jun 26 '18 at 11:40
  • Looks like I read more into this answer than some others do. I did see those implications, but yes, it's a bit between the lines. – mastov Jun 26 '18 at 12:50
  • 24
    A clearer way of saying this would be that the filesystem stores exactly 11 bytes of name, and does not store a location for the .; the location is implicit, and by convention, at position 8. – R.. GitHub STOP HELPING ICE Jun 26 '18 at 14:50
  • 3
    While MS-DOS directly utilized the concept of an extension namespace from CP/M, that came directly from Gary Kildall's use of TOPS-10 concepts (6.3 names). That idea itself can be traced to CTSS, which had files with two part names, but no period. That's pretty close to the dawn of interactive computing. – user71659 Jun 27 '18 at 01:00
  • 2
    It is not simply a matter of display. The operating system has commands that interpret filenames as 8.3 only - for example, anything having to do with wildcards ("*"). You could write a program that would print filenames as 7.4 or 9.2 but you couldn't use DOS commands to find those files using a wildcard for what you claimed was the 4 or 2 character "extension". – davidbak Jun 27 '18 at 10:44
  • @davidbak many commands in Windows still interpret wildcards that way. *.* is not a file with a dot in its name like what one might expected – phuclv Jun 27 '18 at 17:20
  • @davidbak To compound the problem, IIRC on DOS (and Windows) systems wildcard expansion is done by the called program, not the shell. – Alex Hajnal Jun 28 '18 at 11:44
8

Setting aside the file system (other file systems besides FAT were possible on MS-DOS using redirector technology or via the shell approach (ie NetWare)), 8.3 was still a requirement due to the fact that a number of INT 21h functions used the FCB (file control block). (The FCB has hardcoded locations for filename and for the extension.) In particular functions 0Fh through 17h all used FCB(s). (See Ralf Brown's interrupt list.) So a program using FCB functions would not be able to specify a 9 character filename or a 4 character extension.

Additionally the Program Segment Prefix contained two FCBs, so any program examining PSP would need be able to interpret a non 8.3 filename.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
Χpẘ
  • 181
  • 1
  • That reminds me. Do you remember a 512MB limit on hard-disks, because of a limitation on the PC-BIOS. No one sold cheep IDE any bigger than 512MB. My Amiga had a limit of several terabytes per file. So I wanted a bigger drive, but could not get one. – ctrl-alt-delor Jun 26 '18 at 20:10
  • 2
    @ctrl-alt-delor, the limit was 504 MB (or 528 MB if you're working in metric). 1024 cylinders * 16 heads * 63 sectors * 512 bytes per sector = 528 482 304 bytes. – Mark Jun 26 '18 at 20:24
  • @ctrl-alt-delor I don't remember. MSDOS with FAT16 and a 8192 byte logical sector size would give 512MB (64K*8192) max partition size. – Χpẘ Jun 26 '18 at 20:24
  • @Χpẘ it was 512MB or 800MB or something like. It was caused by the incompatible intersection of limits in DOS and BIOS. – ctrl-alt-delor Jun 27 '18 at 13:40
  • 1
    The max partition size in DOS is 2GB, but some BIOS's had a limitation around 500 megabytes. I've used MS-DOS on more modern systems, & it hasn't had a problem with 2GB partitions(of course, it can't use partitions greater than 2GB because of a limitation in FAT16). – JustinCB Jun 27 '18 at 14:42