Hacker News Reader

Comment by silentbicycle | Hacker News Reader

So, yes, ontology tends to break down. Are we going to throw out all existing filesystems, though? Heck no. Fortunately, it's not hard to layer search and non-hierarchical indexing on top of existing filesystems.

I wrote a simple (Lua + SQLite) script that tags files, searches all known paths by tag, etc. It's really not hard. It hasn't been hard for decades. Why hasn't it caught on? Beats me.

Using directories as contexts + symlinks to merge them works around many issues, but the same ugly breakdown appears in e.g. statically-typed OOP class hierarchies. ("Is a platypus a mammal or an amphibian?") Sometimes, is isn't.

Basically, I see where they're coming from, but "normal filesystem, with tags" probably makes more sense to most people than "fully non-hierarchical* filesystem". And, hell, I keep spelling hierarchical wrong.

View on HN

It is not hard but it hasn't caught on because having userspace scripts or daemons running tagging and indexing passes on the files in an existing file system is nowhere near transparent. Even if you use inotify or something to keep track of teh changses in real time, the illusion of transparency will leak sooner than later. And that's when your users' confidence and trust will vanish into the air.

Indexing has to be built in to the filesystem to make the searchs match the state of the filesystem 1-in-1. There's no other way.

I've seen this working live only in the Be Filesystem, or BFS. There you can be sure that if you add an image somewhere, another view of the filesystem will instantly contain the new file and removing it will again banish the image from all other views. The file either exists or doesn't, and you will never notice that a search returned information that isn't no more.

Spotlight fulfills all those requirements.

They address the idea of building a non-hierarchical system on top of a hierarchical one. They argue that doing so is bad because it adds a layer of indirection to your data, and they argue that it's unnecessary since their non-hierarchical system can in fact implement a POSIX-compatible layer easily (so they say).

Interestingly, the original Macintosh File System (MFS, the predecessor to HFS which was the predecessor to the current HFS+) was a non-hierarchical filesystem (that's why HFS has the H). The original Macintosh system software supported hierarchical directories, of course - by maintaining a database mapping file-system nodes to paths. When the user opened a particular folder, it queried the database for nodes whose path matched.

Of course, no database is perfect, and sometimes things got messed up. There was a special key chord the user could hold down during startup that would cause the Finder to rebuild all its databases. When done on an MFS volume, all the hierarchy painstakingly created by the user would be erased, and all the files on a volume would wind up in the root directory.

Reply on news.ycombinator.com