Ever since I started using computers in the nineties of the last century I’ve been noticing different directory structures related to different file systems. Of course, there are differences in the ways operating systems organize files and directories and some file systems can be used in the same way, hence ending up with the same directory structure, but here I am talking about lower level file system structures, such as disk drive mappings and mounted volume placements within the system structure that uses a certain type of file system etc.

The first file system that I came in contact with was the “raw type”, meaning a tape memory “file system”, or to be more precise a bundle of made up file systems and data structures recorded on tapes. For example, I’d “play” the tape to read out something and the program that uses the stored data would read the tape in its own way in an expected order defined by the data structure it is supposed to read from it. I’d have a game that would be split into two tapes, one being the program that would load itself into memory and the other tape would hold level information, maps, midi music etc. Because the game had a certain “flow” to it, from which there wasn’t really much going around and bypassing the needed images, midis, map layout data and other stuff would be recorder on the tape in that “expected” order and the program would quickly retrieve it and present the next screen for me to solve. This way, when the programmers decided to place the data in this raw stream-like manner, there wouldn’t be any holdup, or at least not as much, if you were really good at the game and would be beating it faster than your tape module could read from the tape. It is meaningful to say that I did not understand file systems and data structures at this point in my experience with computers, because in truth I didn’t get to see much “file” systems.

Later on, by the beginning of the millennium I had already had a chance work with PC’s with DOS and Windows operating systems installed on partitions formatted in FAT family file systems, but also with UNIX operating systems installed on partitions formatted in EXT like file systems. At this point I got at that weird situation when I start DOS and I’m expected to switch from one volume to another in order to work with files on my computer. I had two floppy drives, a small hard drive with two partitions and all those letters made things very confusing for me. UNIX on the other hand, that I had much more time to work with was all in a single tree, so all my drives ware there, easily found in one place and also, that great text based game that I used to play in Emacs called Dunnet and all its files in one place. In DOS on the other hand, there was a really good game that required me to insert its second floppy disk with data in order to play. Since I had two floppy drives, the program got confused some times when I placed the floppy disk in the second drive which was labeled as B: by my BIOS. It must have expected it in the A: volume. In UNIX there was no such problem, because I used to have a directory made especially for such purposes and always mounted my floppy drives to that directory and whenever my UNIX programs requested paths to the required data I would point it to that path. Smartly enough those programs asked only once. Every other time they first checked the pervious path and then would ask for a new one if no good data was found, which was next to never.

When Windows became the main operating system in use at home I was already used to drive letters tearing into pieces my logical way of thinking about computer data organization and at that point I didn’t use the old UNIX machine much. The whole drive thing got more and more confusing when I got to install new hard drives in order to make more space. The first time I had a memory shortage was when I filled up the My Documents folder with save game data, midi music files and the Program Files with programs, games etc. When I finally had the hard drive installed and the partition created and formatted a new letter appeared.

The computer’s file system structure began to look like a forest. In UNIX there was just one tree branched down into logically organized manner and in Windows there was a forest of these trees.

The C: tree was the most confusing. I had an Atlas program that installed itself into C:’s Program Files and recommended that I allow the data folder to be on another drive if possible. Since I had D: and now after the new hard drive even an F: drive I picked D: for it. When I ran the Atlas program it requested that I insert my original CD (checking if I have a “legal” installation - I could have copied the CD… dah?). So, the whole thing ran from three separate volumes.

I won’t comment how FAT family and NTFS family are almost identical, because I’d like to be spared the logical and functional difference propaganda, because I know the specifications for both file system families. Here I am talking about file system structures and not their security or performance qualities.

When I compare the three data storage models that I have had experience with, I notice that there are a few branches.

The first one I’ll revise is the FAT model where there are volumes mounted as distinct drive letters. Aside of data storage devices, these file systems do not let their operating systems create files that directly take other programs to other devices and hardware components. Be it because the operating systems are not designed that way or because it is not practical or possible, I notice that it is not possible. The file system does not provide a way to lookup devices. As for file and folder attributes, they are very primitive and the advances we can see in newer releases of the Windows operating system implement the file and folder ownership and permissions to the system level instead of recording it within the very file system structure and its records.

The second is the EXT like file system. There are two types I know of, the static type which is the UNIX native and the journaling type which is supported by Linux operating systems. I find this file system modelling more natural in sense that it does not cut the physical computer into a forest of “hanging out there” components that must be viewed as separate and unrelated. Also, the fact that the file and directory permissions and both user and group ownership and management of rights of access is much more flexible makes this approach favourable by me. Another thing is that the journaling type eliminates the need for long and useless “file system checks” that NTFS and especially FAT file systems demand from the operating systems after unclean and unexpected shutdown. The journaling type is modelled to grantee consistency of file content and the file allocation table at any point, regardless of whether or not the writing was complete and the file closed at the moment of unexpected shutdown. In any way, the lack of a forest of floating in space meaningless labels is a bonus, because when I want mount my storage devices I don’t just want to label them. I also want to organize them in different places. I want to mount hard drives on higher shells in one directory, lower shells in another and to mount external drives in directories in a completely different place etc. This is what I find great with EXT like file systems. It is the flexibility.

The third model is the complete absence of any file system. Just a plane raw stream-like data structure bundle made in such a way that only the programs meant to use it can use it. The good and bad sides of this way of using data storage devices or partitions on it is clear without me having to explain, but I find the efficiency it potentiates very attracting.

There you have it. This was an insight in my way of viewing the file systems that are in use today. Who knows? Maybe when I see that loudly announced database-like file system model I’ll change my verdict on the best file system to pick for an operating system (if I decide to make another one... again).