Single level file directoryUsing a modern microcontroller to explore early home computing conceptsWas it Microsoft that started the war between Application and OS vendors?What file systems / encapsulation formats used ASCII?What was the point of Apple Pascal having its own file system?Where was the Willowsoft Overture File System (OFS1) used?File system performance and the Unix APIWhen did Multics begin using '>' as a pathname separator?Where was the DOS cdd utility from?Starting a multi core CPU as single coreProtected/virtual memory support in classic AmigaOS
Who voices the character "Finger" in The Fifth Element?
Which is better for keeping data primary partition or logical partition?
Skipping over failed imports until they are needed (if ever)
Does any Greek word have a geminate consonant after a long vowel?
Can two or more lightbeams (from a laser for example) have visible interference when they cross in mid-air*?
Integral from infinity to infinity
Details of video memory access arbitration in Space Invaders
Can an editor review manuscript without sending to reviewers?
What are good ways to spray paint a QR code on a footpath?
Was it really unprofessional of me to leave without asking for a raise first?
Sharing referee/AE report online to point out a grievous error in refereeing
Balanced parentheses using STL C++
Why does the same classical piece sound like it's in a different key in different recordings?
In native German words, is Q always followed by U, as in English?
Symbol for "not absolutely continuous" in Latex
Most important new papers in computational complexity
Graph problems as integer programs
How to answer "write something on the board"?
Most elegant way to write a one shot IF
Should I report a leak of confidential HR information?
Could the Q destroy the universe?
Can Aziraphale and Crowley actually become native?
Do launching rockets produce a sonic boom?
Different budgets within roommate group
Single level file directory
Using a modern microcontroller to explore early home computing conceptsWas it Microsoft that started the war between Application and OS vendors?What file systems / encapsulation formats used ASCII?What was the point of Apple Pascal having its own file system?Where was the Willowsoft Overture File System (OFS1) used?File system performance and the Unix APIWhen did Multics begin using '>' as a pathname separator?Where was the DOS cdd utility from?Starting a multi core CPU as single coreProtected/virtual memory support in classic AmigaOS
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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.
operating-system file-system
add a comment |
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.
operating-system file-system
1
By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"?
– Jeff Zeitlin
8 hours ago
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
8 hours ago
add a comment |
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.
operating-system file-system
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.
operating-system file-system
operating-system file-system
asked 8 hours ago
DYZDYZ
1356 bronze badges
1356 bronze badges
1
By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"?
– Jeff Zeitlin
8 hours ago
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
8 hours ago
add a comment |
1
By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"?
– Jeff Zeitlin
8 hours ago
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
8 hours ago
1
1
By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"?
– Jeff Zeitlin
8 hours ago
By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"?
– Jeff Zeitlin
8 hours ago
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
8 hours ago
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
8 hours ago
add a comment |
5 Answers
5
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
1
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
1
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.
– Euro Micelli
7 hours ago
add a comment |
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.
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.
1
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
7 hours ago
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.
– another-dave
3 hours ago
add a comment |
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.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "648"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f11467%2fsingle-level-file-directory%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
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.
edited 2 hours ago
answered 7 hours ago
manassehkatzmanassehkatz
3,4147 silver badges25 bronze badges
3,4147 silver badges25 bronze badges
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 8 hours ago
Will HartungWill Hartung
4,24610 silver badges23 bronze badges
4,24610 silver badges23 bronze badges
add a comment |
add a comment |
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.
1
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
1
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.
– Euro Micelli
7 hours ago
add a comment |
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.
1
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
1
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.
– Euro Micelli
7 hours ago
add a comment |
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.
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.
answered 8 hours ago
Jeff ZeitlinJeff Zeitlin
7123 silver badges10 bronze badges
7123 silver badges10 bronze badges
1
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
1
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.
– Euro Micelli
7 hours ago
add a comment |
1
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
1
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.
– Euro Micelli
7 hours ago
1
1
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
All the Atari DOSes as well.
– Maury Markowitz
7 hours ago
1
1
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.
– Euro Micelli
7 hours ago
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.
– Euro Micelli
7 hours ago
add a comment |
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.
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.
1
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
7 hours ago
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.
– another-dave
3 hours ago
add a comment |
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.
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.
1
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
7 hours ago
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.
– another-dave
3 hours ago
add a comment |
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.
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.
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.
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.
answered 7 hours ago
TommyTommy
17.8k1 gold badge51 silver badges89 bronze badges
17.8k1 gold badge51 silver badges89 bronze badges
1
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
7 hours ago
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.
– another-dave
3 hours ago
add a comment |
1
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
7 hours ago
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.
– another-dave
3 hours ago
1
1
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
7 hours ago
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
7 hours ago
2
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.
– another-dave
3 hours ago
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.
– another-dave
3 hours ago
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 3 hours ago
another-daveanother-dave
2,0446 silver badges20 bronze badges
2,0446 silver badges20 bronze badges
add a comment |
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f11467%2fsingle-level-file-directory%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
By "single layer" do you mean "didn't support subdirectories/folders"? Also, what do you mean by "limited capacity"?
– Jeff Zeitlin
8 hours ago
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
8 hours ago