Have there actually been any commercial operating systems with a single-level, limited capacity file directory? I remember vaguely that the early versions of MS-DOS FAT12 may have had a single layer, but I could not find any references.

  • 1
    By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"? Jun 25 '19 at 17:49
  • Yes, flat rather than hierarchical. By limited capacity, I mean that there is only a fixed number of files (say, 256) that can be stored in the directory (and, therefore, in the whole file system).
    – DYZ
    Jun 25 '19 at 17:57
  • 4
    Basically all early commercial OS's had this - if the total capacity of your medium (floppy, DEC tape, very early harddisk...) doesn't allow that many files, you don't need subdirectories. IIRC Multics was one of the first OS to introduce them, Unix copied this, and from there it spread.
    – dirkt
    Jun 26 '19 at 4:48
  • 4
    MS-Windows to this day has its directory separator the wrong way around, because DOS 1 had no directory hierarchy. They added command options e.g. /w, first, then when they added sub-directories, they could not do what everyone else was doing, so they chose what seemed, to them, like the next best thing. `\` Jun 27 '19 at 9:32
  • 1
    original MDOS for D40/80 FDD/FDC for ZX48K compatibles had just single directory and 128 files max ...
    – Spektre
    Jun 28 '19 at 15:24

The whole CP/M family of operating systems, until Concurrent DOS, had both a limited number of files per drive and no hierarchy except for user areas. From the Wikipedia article:

CP/M 2.2 had no subdirectories in the file structure, but provided 16 numbered user areas to organize files on a disk. To change user one had to simply type "User X" at the command prompt, X being the number of the user wanted; security was non-existent and not believed to be necessary. The user area concept was to make the single-user version of CP/M somewhat compatible with multi-user MP/M systems. A common patch for the CP/M and derivative operating systems was to make one user area accessible to the user independent of the currently set user area. A USER command allowed the user area to be changed to any area from 0 to 15. User 0 was the default. If one changed to another user, such as USER 1, the material saved on the disk for this user would only be available to USER 1; USER 2 would not be able to see it or access it. However, files stored in the USER 0 area were accessible to all other users; their location was specified with a prefatory path, since the files of USER 0 were only visible to someone logged in as USER 0. The user area feature arguably had little utility on small floppy disks, but it was useful for organizing files on machines with hard drives. The intent of the feature was to ease use of the same computer for different tasks. For example, a secretary could do data entry, then, after switching USER areas, another employee could use the machine to do billing without their files intermixing.

As far as the number of files, that was not much of a problem on floppy disks, but a big problem on hard drives. I remember patching MP/M-86 on an Altos 586-20 to increase the number from (if I remember correctly) 1,024 to 2,048 files. That was a bit risky, since I didn't know all the internals of MP/M-86, but in the end a few small changes and reassembly of those files, and backup/restore of the hard drive, and I had a system that lasted me quite a bit longer than it would have otherwise.

With Concurrent DOS, the CP/M family (at that point CP/M had gone from CP/M-86 (16-bit) to Concurrent CP/M and MP/M-86 (multiuser/multitasking) and then added MS-DOS compatibility) added full MS-DOS hierarchical directories. Once you have hierarchical directories, the number of files in the root directory is still limited in some systems but largely irrelevant because you can simply create subdirectories to hold more files.


Most early microcomputer operating systems were single-level - Apple DOS, CP/M, MS-DOS/PC-DOS prior to version 2.0, UCSD P-System, whatever Commodore called their DOS for the PET/CBM and C64. With the exception of UCSD P-System, which had a maximum of 77 files in the directory, I don't believe any of them had an inherent limit to the number of files, but most of them did have practical limits due to the amount of space allocated for the directory.

  • 2
    All the Atari DOSes as well. Jun 25 '19 at 18:58
  • 3
    MS-DOS (FAT12 and FAT16) has enough directory entries for exactly 112 files at the root directory. Unless you use sub-directories (or in versions before DOS 2.0 where directories are not supported), that’s the hard limit on how many files the media could hold. Each first level sub-directory takes one of the 112 root file slots. The count of files in a sub-directory is limited only by media capacity. LFN support since Windows 95 can reduce that limit dramatically because storing Long File Names takes one or more additional file slots per file with LFN. Jun 25 '19 at 19:13
  • 1
    On the Acorn BBC Micro, the built-in tape filing system had no directories at all. The original Disk Filing System (DFS) gave each file a single, one-character ‘directory’ (the default being $ if unspecified). But the later Advanced Disk Filing System (ADFS) was fully hierarchical.
    – gidds
    Jun 26 '19 at 16:23
  • With the commodore machines maybe it's more the drives than the computer itself because the drives are ”intelligent” of sorts: they have a processor, RAM, and the disk/file layout code lives in the drive's ROM. The 1541 drives for instance don't have (sub)directories and are limited to 144 files, but the 1581 drives have a file type DIR and allow ”partitioning” the disk into subdirectories – even nested. Third party vendors e.g. of hard drives even have subdirectories like we are used to today built into their drive's code.
    – BlackJack
    Jun 27 '19 at 20:07

In addition to the examples already given a couple more used a flat data structure with an absolute limit on the number of files but one property assigned to each file was its directory. So the real storage was single level — a single data structure, with file names being required to be unique across the entire disk — but it was presented as if a single level of directories.

The Macintosh File System, the predecessor to HFS that lasted for only just more than a year, was one such; the maximum file count was a function of volume size, and worked out as 128 for the machine's original 400kb floppies. A file's directory information was stored in the desktop database, so rebuilding the desktop would flatten the disk's hierarchy.

Acorn's DFS is another, even more limited implementation — the pseudo-directory names are only a single character in length and only 31 files are permitted per disk per side, disks initially topping out at 200kb/side.

  • 2
    Acorn DFS treats each side of a floppy as a separate disk. While this means that you can put an additional 31 files on the other side, it means you can't have any files (or folders) spanning both sides of the disk. The subsequent ADFS interleaved both sides into one logical disk, added proper directory support, and generally sorted things out.
    – Kaz
    Jun 25 '19 at 19:19
  • 2
    The Eldon2 (late 1960s/early 1970s) file system had a single flat namespace for text files, so names globally unique, but files tagged with owner identifier. Jun 25 '19 at 23:01

Yes. Several. Consider, for example Dec RSTS/E. This was a flat directory structure.

Now, to be clear, the system had separate accounts. So, each user would have their own account/directory. Very similar to Users in CP/M. But they weren't hierarchical.

As for RSTS/E file capacity, I don't know the specifics, but I'm sure it had a limit of the total number of files on a specific device. Even modern Unix filesystems have limits to the number of files they can have. They just tend to be absurd limits.

  • Technically, wasn't CP/M similar to RSTS/E?
    – RonJohn
    Jun 26 '19 at 21:31
  • Only at the most basic level. They both used DIR and PIP, but that's about as similar as it gets. Jun 26 '19 at 22:18

Does 'single level' mean exactly one directory a la early DOS floppies, i.e., no directories other than the root?

Or does it mean multiple directories, no nesting, except maybe of user directories in the root directory? So you have directories /foo and /bar, and we can overlook the fact that there's actually a directory called / which contains foo and bar?

For my answer I'm going to assume the latter, since the users of such systems tend to regard them as single-level directory systems.

In which case: I'd guess this was once more common than hierarchical directory systems. The influential description of hierarchical systems was this document from 1965. But even after that, there were single-level systems. The early DEC systems I used -- TOPS-10, RSX-11M, RSTS/E -- supported one level of directory, and tended to conflate "directory" and "user".

I think the only system I used before about 1980 that had nested directories was GEORGE 3 (on ICL 1900), and that was definitely influenced by the Neumann/Daley paper.


I'm not sure about the PET or VIC20, but the C64, C128, C128D, Plus/4, C16, and related machines used a ROM OS, rather than a DOS. That said, they all used basically the same flat disk format, with a limit of 144 files per directory. With the 1541, there were a total of 664 blocks per side of a disk, but one could only access one side at a time. With the 1571, you could access both sides of a double-sided disk, for a maximum of 1328 blocks.

Commodore also made a B128, but that was a very different machine, and I don't really remember much about it besides it actually loading files at a reasonable (compared to the C64/C128) speed. We had a B128 with an internal floppy disk, and I can't find any details about this online to confirm my vague recollections.

  • 1
    I'm pretty sure the Commodore machines leave the filing system stuff, including directory structure, to the drives. So the VIC-20 has exactly the same disk structure as a C64 because it is paired with the same drive in the C1541 (or it's slightly faster predecessor, the C1540 — the 1541 is just a ROM swap, to make the drive communicate a bit slower by default, because the C64 is a bit slower than the VIC-20 in CPU terms).
    – Tommy
    Jun 27 '19 at 3:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.