I have also considered Evernote to handle my document storage (and always accessible, including search) accompanied with its tagging features but I found it too slow and plain directories combined with Spotlight worked better for me. These directories are in my Dropbox folder so I can access them anywhere, some hierarchies are applied for Bank statements etc. but most files are in one big folder. It's a pity there is no good searching in documents from the Dropbox site.
I've been meaning to find which one of these fits my workflow:
Quicksilver tag plugin [http://lifehacker.com/169971/metadata-as-a-filing-system]
They all use Spotlight metadata to accomplish the tagging, Punakea seems the most modal, which I like less.
But really I think the author just needs to discover 'locate'...
1. Using an OS's comments/metadata field to store tags and include them in a desktop-search program -- the comments/metadata field is not compatible between operating systems and can be lost while copying files between filesystems or operating systems, so this is not a robust solution. And currently only OS X supports comments/metadata field for all file types.
2. Using a central database that does all the file-to-tag association -- this may be 'less universal' or robust than #1; to be cross-platform this requires someone to write a new program that plugs into a given OS and runs constantly monitoring files in case you move or rename them.
3. Storing the tags in the filename itself -- this will give you long, ugly filenames, but should be the most robust because all of the modern OS's and filesystems support 256 character filenames (usually including the path) which gives plenty of room for a number of tags separated by some kind of delimiter character e.g. filename###tag1#tag2#tag3.ext . This would need just a simple tag-management program to help you tag files (and can function as a nice file explorer as well, like http://www.nudgenudge.eu and its clone http://lunarfrog.com/taggedfrog) which does not need to be constantly running, and could use whatever desktop-search program to use the files.
Therefore at the moment I think #3 would be the most robust and versatile solution. Then someone just has to make a frontend for file renaming and tag-database storage/rebuilding from filenames/viewing...
I hope I'm not misunderstanding you, but I think that's exactly what I was trying to suggest in the article. The idea was that you could have:
and that would be identical to:
etc. To put this broadly in terms of data structures, our current filesystems use an ordered list, whereas I'm proposing using an (unordered) set.
The only problem symlinks can address would that of having files available under multiple locations. But that's still strictly hierarchical and bound to become a maintenance nightmare soon (just think about file renames).
Tag based filesystems are indeed an interesting idea and a somewhat logical next step from the traditional hierarchical fs + desktop search tandem that is commonplace now.
This would end up being a maintenance nightmare for different reason, though. You'd end up with two dirs, for example work/projectX and projectX/work, with some files in one and some files in another. Strict hierarchies don't map to tags.
I do believe that desktops will lose their significance over time and the web experience will be the next thing.
And then it may even migrate to the OS itself, because it will be the familiar thing.
And yes, MS claimed their project, 'WinFS', would be a key part of Vista (aka Longhorn), but then dropped it in 2006.