@iansjack, yes, the relationships do exist (because I'd probably go with sqlite3), and the various queries and operations available to such a database would also be important. Those queries would be important, for two reasons:
1. from what I've seen, a database can be much smaller than other files. Compression can also be applied, making files even smaller if they're not already compressed.
2. A single select statement can be incredibly fast. I haven't tested this on a database with, say, a few thousand (or even hundred thousand) rows, but will certainly need to do so to see if this would be viable.
As an example of the databases structure, in sqlite3, the following statement might create the files table, whereupon a relationship could be created between other tables, using the USTAR format as an example:
Code:
CREATE TABLE files(
id INTEGER NOT NULL PRIMARY KEY,
filename TEXT NOT NULL,
mode TEXT NOT NULL,
uid INTEGER NOT NULL,
gid INTEGER NOT NULL,
size INTEGER NOT NULL,
mod_time INTEGER NOT NULL,
checksum TEXT NOT NULL,
type TEXT NOT NULL,
linked_file INTEGER,
owner_username TEXT NOT NULL,
group_name TEXT NOT NULL,
dev_major INTEGER,
dev_minor INTEGER,
prefix TEXT NOT NULL,
contents BLOB
);
The only problem with using SQLite3 is that it doesn't have as rigid of a type system as other DBMSs, but that's a sacrifice that can be made, as the user won't be directly managing the database (unless they extract it from the disk, which is possible).
The huge advantage is that they could store all their files in a database that would be a single database on other FSes. The other advantage is that pseudo FSes could also be created as in-memory file systems (i.e. /proc) and then a hook could be made in the file system driver to transfer your request to the in-memory file system when you attempt to read from anything and its path starts with /proc, for example.
There are probably other things I'm missing in regards to advantages/disadvantages, but for right now its just an idea and I don't know if something will become of it or not.