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.
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.
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.
I think it boils down to this: for hierarchical data, use hierarchies. I believe that files on a modern personal computer will almost certainly not be hierarchical, so it's not ideal to store them hierarchically. Videos, for example, may be movies, tv shows, screencasts, music videos, etc. Videos may also be standard definition, 720p, 1080p, etc. It's difficult to say, for example, which attribute should be the root directory for your videos, since it's reasonable to want to browse by many different attributes. A hierarchy does not apply to videos, but attributes could easily be represented by tags.
E.g if I need to organize my books, I could move it only to a given position, not another one, I could add labels to my books like "history", or "Initials of the author", but I could only group one way, like all my science papers on one place, if I want to group all the books that talk about sex, or crime, I will have to destroy the other group.
With computers you could create multiple directories trees with links instead of data, so I don't need to multiply the data each new tree. The tech is there(inodes).
Imagine if you study countries according to their population, so you create a hierarchy "most populated", "less populated", "no populated at all", then inside most populated you have "the most populated", "the less populated", and so on.
Then you could have another directory according to the extension in squared kilometers. Another according to their capital coordinates, and so on.
And Google is nowhere near hierarchical.
-sent from your iPhone (you should lock it)
In smaller data sets (eg not Google scale), where all the items are about roughly the same thing, you need some human classification for your search to work well.
In my experience, if you can make entering more structured metadata just as easy, people will enter it, and you get a big return in the ability to use the information you've collected.
However, hierarchy itself is still incredibly valuable. People think in terms of hierarchies - it's just that they think in terms of multiple hierarchies and an item will almost always belong in more than one place in those hierarchies.
If you allow users to describe items in the way which makes sense to them, and then search and browse by any of the terms they've used, then you've eliminated almost all the frustrations of a file system. In my experience of working with people building complex information applications, you need:
* deep hierarchy for classifying things
* shallow hierarchy for noting relationships (eg "parent company")
* multi-values for every single field
* controlled values (in our case by linking to other items wherever possible)
Obviously, there are some issues that would have to be resolved. For instance, you would have a have some kind of uniqueness notion for tags in order to simulate current hierarchical file systems, or two paths in the traditional sense might be the same. Since not all tags would have such uniqueness constraints, there would also have to be some kind of tag type (or property type), and at that point we're getting awfully close to what databases do.
Present-day hierarchical file systems are digraphs, not trees.
Fortunately, Windows moved in a better direction since then, with user home directories and most user data stored effectively underneath then, more organization to the Windows directory, and so on.
For example, I have a document which I want to put onto a USB stick for a friend. I have no idea how their search metaphor lets me do this. I search for the document, but now how do I "move" it? Does "moving" even make sense? Now I'm not doubting that they do have an answer for this, but is the answer something that will be easy to explain?
If you just start with hierarchy, and put a working search over the top of it, then it has a nice model that is easy to explain. All files have an address (like a URL), but if you don't know (or can't be bothered to type) the address, then you use the search box (like google).
does that make sense?
This is why I think non-HFS ideas work better as indexes on top of existing systems. We don't have the right metaphors yet.
As far as metaphors, I'd say think of calling someone on a landline vs. a cell phone. With the cell, you don't have to specify where or who joe is (/people/friends/joe/house|work|carphone|vacation|etc.) in order to reach him since joe's 1 cellphone number rings wherever he happens to be.
Another example is folders on the iphone -- moving an app into a folder with other apps doesn't actually move the app from /homescreen/app1 to /homescreen/games/app1 on the iphone hard disk (as far as I know...), it just changes the superficial hierarchical view of the data.
A hard link basically gives multiple paths to the same data, sharing attributes like the owner and permissions. Using any linked path will change the file. The exception is that "rm" deletes just one link (hence the system call "unlink"), and the file is only lost when all its links are gone.
2 The Hierarchical Namespace Albatross
2.3 Performance Limiting
3 hFAD: A New File System Architecture
3.1.1 Naming Interfaces
3.1.2 Access Interfaces
3.2 Index Stores
3.3 OSD Layer
4 Open Questions
Also, they say: "Note that we are not condemning hierarchy in general; indeed, hierarchy can be useful in a variety of situations. Rather, we are arguing against canonizing any particular hierarchy"
I naturally have a Movies directory and a TV directory. Under each I have two directories SD and HD. Sometimes I may want to simply browse all the HD video on my system.
Where do music videos (i.e. live concerts) go? They're certainly Music, but it's fair to imagine wanting to see them listed when I'm browsing through Movies and not listed when I'm browsing my mp3's. Add in tutorial videos for music production software (I have a lot of these) and it's even more of a guessing game.
ie: have some \sound\mp3\all "virtual directory" automatically populated will all the mp3 files of my system.
Now that I think of it, it would be cool to be able to express such "virtual directories" by way of declarative filters.
eg: mkdir ./bigfiles ./ -r 'file.size > 100mo, subdir by file.year/file.type, file.type isnt tmp' -- ..., you get the picture
(Yes, I get what you're saying - you want to impose a structure on that smart folder via the metadata. It was just too tempting to make a stupid comment ;)