Geeks With Blogs

Elton Stoneman (@EltonStoneman) IT Consultant, integration specialist, @Microsoft MVP and @Pluralsight author.

The file system in RobOS is very WinFS-esque. WinFS and database driven file systems are the natural progression. Journaling file systems like ext3, reiserfs, and xfs are making their way into Linux systems so it makes sense that Apple and Microsoft would make their own versions.

Here are the key points of the file system. I have no cool name for it yet, but I'm sure something will come to me or suggestions are welcome too.

Relational Database

Files relate just like rows in tables so having a relational database drive the file system makes things like searching incredibly easy and useful. Information has relations because in most instances your application files relate in some way. You have an excel, word, and powerpoint document for X company. You have 3 Word files that relate to the same subject, and the list keeps growing. Making the relations of the data will be hard but it is possible with a few techniques. The database is used to house the information about files, not the data it contains.

Customizable Entities (Tables)

Unlike WinFS, you can design all of the meta-data. It'll be a lot like designing tables in a RDBMS because essentially the information stored with files will be stored as meta-data in tables. A text based editor will be out of the question along with any text based manipulation. Why? Error handling. If I have to add extra lines to make sure you're typing Hello instead of Helo then I'm wasting both of our time. I've done away with INI files or any kind of text based configuration simply because of the umpteen error handling functions you have to add just to make sure the information is valid. With a binary approach, the information is either valid or invalid there is no in between and that's how I like it.

Files won't be stored in the database, only the meta-data. Try storing all of your files in a database and then have the database crash. You'll then hate the idea and never do it again. I've never had this happen but I'm not about to try. Plus the bigger the database, the more memory you need, etc. Keeping the database to just text will significantly shrink it while keeping things like searching to an easy method.

Virtual Partitions

I like my Windows disk drives the way most OEMs make them: 1 main partition (sometimes there's a small one for BIOS stuff but that doesn't count). This makes sure I don't have to resize partitions later or do any funky stuff to keep the partitions clean. This is a problem when I redo machines as I literally copy stuff off, then move it back but I prefer this method. I have the most space in the place I need it most but it does offer a little bit of an unorganized feel. What if I had all of my music on one partition? My music collection would grow passed the partition most likely and resizing is something I don't do, even if there is such a thing as dynamic disks in Windows. Partition Magic made me hate this practice to this day because of wonderful war stories that I'm not about to go into.

So the core of the OS will be on one partition. This means that if you want to run RobOS it'll be on one partition. Will you need more? No. You'll only need more if you run a different OS. Virtual partitions will break up the bigger partition into a more logical structure.

There are 4 major components of the virtual partition structure:

  1. Operating System
  2. Applications
  3. Configuration Data
  4. Application Files

The OS partition (OP...P?) will be a locked, non-readable partition. This means that trying to find files or folders here will be impossible. Why? You don't need to mess with core OS files whatsoever. Microsoft may let you touch kernel32.exe but I'm not about to let you. Not knowing the common files means viruses can't be made to mimic the names. Also since the OS files will only exist here, there is no way in hell a virus can be mistaken for a real program. Can you see the program? Then it's not an OS component. OS components are hidden and will only be touched by the updater or the installer if you choose to add components. This also keeps all of the OS in one location which makes defragmentation simpler if not very quick. If OS components never get written to the partition (only during install/update) then they should have very little fragmentation if at all. Only the OS will know the internal structure of this partition and the partition will be encrypted completely to make sure no outside tampering is possible.

The Application Partition(AP) will be a locked but readable partition. OS applications will be locked completely in the same way the OS is locked. Developers will have the ability to lock their applications at will. Developers can leave their application open but generally it's not a good practice as virus makers will be looking for these holes first (since I'll do my best to never give them any others).

The Configuration Partition(CP) is basically a form of the Windows registry. It'll house the configuration information for the OS as well as all Applications. OS configuration will be locked from outside access. The only thing changing it will be the GUI and a limited API. The API will have checking to make sure no malicious intent is used and if anything is suspected the application will be shutdown and quarantined until it is fixed. I'm not taking any chances of corruption from any sources, period. Application data will have the ability to be locked as much as the OS data is. Developers will be encouraged to make it impossible to make changes except through API calls. There will also be a core API to facilitate configuration management but there'll be more on that later.

The Application Files Partition (AFP) will house all of the application information on the system. This is commonly known as things like Word documents, MP3 files, Text files and any other file types usually. This partition will be completely open and unable to be locked unless I find a need to lock certain sections of the partition. This will be the majority of the use of the relational database portion of the file system since OS files and configuration data won't really have much meta data that a user needs to search on. To put it simply, the user shouldn't need to know about the OS at all. They're only interested in their files and guess where they'll be? Here.


I love what WinFS is promising. Honestly in today's information age, there's more of an information overload than anything useful. All Operating Systems now offer information, but do very little in the way of management of the information. This is an attempt to help manage the information while keeping users glued to what they really use a computer for: the applications. While I am taking away much of the OS from the user, I'm replacing it by giving them control of the parts they really want. It'll seem very constricting at first but over time I think this concept will catch on.

These are just concepts right now and if someone provides a better alternative I may look into that. The goal is to produce a reboot-less, virus-less PC and I think given the knowledge and application I can do it. The virtual partitions will be hard to actually develop but if they're done correctly it's a step in the right direction.

Posted on Monday, August 2, 2004 6:38 PM | Back to top

Comments on this post: RobOS: File System of Champions

# re: RobOS: File System of Champions
Requesting Gravatar...
Hi Jeremy!
After a long time...

> The database is used to house the information about files, not
> the data it contains.

So does this mean the database will contain some info about files, plus some kind of a pointer to the actual file? In that case this database will be a kind of index. Maybe something like the ones that today's desktop search tools use?!

> Keeping the database to just text will significantly shrink it
> while keeping things like searching to an easy method.

How to go about multimedia files? Maybe extraction of some useful data from a multimedia file and storing it in the database will be a good idea. Then the user can further edit this metadata if he'she wishes to. e.g., add some descriptive text in the metadata for an image.

> The Configuration Partition(CP) is basically a form of the
> Windows registry. It'll house the configuration information for
> the OS as well as all Applications. OS configuration will be
> locked from outside access. The only thing changing it will be
> the GUI and a limited API.

Will this API do something like code scanning?

I gotta hurry to office now, will be back here later.

Left by Kapil D. Pendse on Nov 17, 2004 10:23 PM

# re: RobOS: File System of Champions
Requesting Gravatar...
Jeez it took me forever to respond and you may not even be keeping up with this still.

Yeah the database would just be an index. I've not dealt with databases that store data as a BLOB inside it. I'm not looking to create a multiple gig single database file to store all the bits. In many ways it was like the now-defunct WinFS. I just wanted to store the metadata for everything inside a single point instead of going to each individual file for it.

Re: Multimedia files, the database metadata would be just for that alone. It'd store your ID3 tags and other information so that the data itself is just bits. If I had to guess this may be where WinFS faultered. We're talking stripping a massive amount of files in an existing structure (in *nix, Mac, and Windows) and basically saying "Hey, forget all that and do it *this way*"

Re: Configuration partition. That's simply the registry in Windows, ini files, data configuration, or anything with respect to changing how a program functions. By segregating the data based on the most recently accessed information, it keeps the fragmentation to a minimum. The first two partitions will almost never be touched except for upgrades to the core OS or any third party apps. The second two partitions will be most frequently changed. Any time your program updates a config parameter it'll be dumped in the files in the configuration partition. Any time you download a new mp3 it'll dump in the AFP.

Most of this is kind of an added unnecessary layer of abstraction. I mean it does look great on paper but to implement such a system would pretty much have to be from scratch in an OS that has almost no compatibility. How would you turn Windows, *nix, or a Mac into this? Not terribly easy at all and that was my original goal of the entire project, something tacked onto Windows.
Left by Jeremy on Dec 15, 2008 1:29 PM

Your comment:
 (will show your gravatar)

Copyright © Elton Stoneman | Powered by: | Join free