Home Forums FineTunedMac Community Lounge The End Of Folders?

Hang on to your folders boys and girls. If I correctly read the runes from the 2013 Apple Developer's Conference keynote description of Maverick, Apple is moving toward a folderless universe or perhaps a "Smart folder" universe. With the expanded "tagging" capability of Maverick folders, as we have known them all these decades (generatis?) won't disappear overnight but tags and smart folders have the potential of making folders largely obsolete (or maybe the British term redundant is more accurate). There is nothing particularly new about file tags, they can be thought of as a throwback to pre-OS X file attributes. Sherlock from the earliest OS X days has evolved to Spotlight and Spotlight powers Smart folders in Finder and several other applications. It is not new technology at this point rather a logical extension of already proven technology.

If I am correct we are going to have to learn to think less bout "where" a file goes and a lot more about what "identities" we want to tag the file with.

I think I'm looking forward to this. I use a lot of smart folders in iTunes, and love the ease of organization, but I haven't forced myself to use them in a regular Finder sort of way. So this might just be the kick I need. Being able to label the same file with several tags and have it appear when I need it just makes sense to me.

Now where'd I put that floppy drive....

Oh my (or oy veh! as the case may be), that will take some adjustments on my part. But then, so did OS X. And now, easy-peesy. Well, I do find that I usually check to ensure I'm in the right Library…

Back in the early days of OS X, maybe 10.1 or 10.2 some apps would prompt for file "attributes" when you clicked Save. It wasn't all that useful in the days of Sherlock with its limited indexing capacity but with Spotlight and smart folders it becomes an essential tool. Substitute Tags for Attributes and adding that back in as an optional feature would be a nice Maverick adaptation for applications. Maybe making that an enhancement to the standard Save dialog API.

I haven't written any serious code since I retired in 2000 but I can envision some usefull new applications enabled by or in support of this new functionality. It may be time for me to brush up on Objective C and Xcode.

Back when Windows Vista was first being developed, Microsoft talked up a new filesystem for Windows. This newfangled filesystem, called WinFS, would not be a "directory" the way disks have had since the dawn of time. Rather than just being a table that contained lists of file names and the places on the hard disk where the file was located, arranged in a structure that described what file was in what directory, WinFS would be a database. The database would contain all kinds of info: name of the file, type of file, location on the hard disk, and almost any kind of other data you could imagine. And, as with any database, it could be searched easily, quickly, and powerfully, returning results for, say, "all files in this folder," "all files modified on this date," "all files having something to do with my taxes," "all files having something to do with my taxes from 2012 or 2011," "all files that aren't Excel spreadsheets having to do with my taxes created between last February and last May," "all files having to do with my taxes except Excel spreadsheets that also list expenses on my house," and so on.

It was a great idea that went nowhere. They couldn't get it working, and it was removed from Vista.

It's still a great idea, though. Since a normal hard drive these days almost certainly has over 200,000 files and can easily have north of 600,000 files on it, the traditional way of making directories and organizing files doesn't work well any more. Searching is too cumbersome and slow, and file management takes way too much effort.

tacit: sounds very much like how MS converted preference files into the horror that is the Registry...

The Registry is a horror; it was a bad idea from the beginning.

A database-driven disk directory is actually quite a good idea, and I'd love to see it happen. It seems to be a nontrivial implementation challenge, though.

I think it's too big of an "all the eggs in one basket" risk. One file that tanks the entire system if it gets corrupted or lost. Like what happens when the registry goes to pot on a windows box. Nuke and Pave.

I replace enough failing hdds to see the averages. And when ditto'ing over a failing drive, I look through the files that were not copied due to io errors, to see what I need to look into after reassembly. Sometimes I see critical OS files damaged, or preference files, or say the itunes library database (sucks to be you!) A few times I've seen things like /private get trashed. And that takes out a lot of important things, specifically netinfo/ldap. And then you're reinstalling.

I suppose theoretically directory services could do it just fine? It's basically the registry for mac, but contains far less app-specific data. But it can be used by anyone to store anything. I think apple is trying to keep apps from messing with DS because they've seen what happened with the Registry. (in windows' case, it's more a matter of security... he who controls the registry controls the computer, pretty much every windows virus/trojan/malware has "break into the registry" at the top of their "things to do" list, and windows just can't seem to keep them out, many hundreds of holes have appeared over the years)

That's what the current disk directory is, though. One "file" that tanks and takes your whole system's contents with it. The fact that we don't normally think of the directory as a file doesn't make it any less prone to this.

For all intents and purposes, your HFS+ directory is a database; it's just a database with no built-in integrity checks, no way to search efficiently, and limited metadata.

While I agree that it behaves like a database, its not a "flat file", and there are a large number of good tools out there to fix it. of course, if your directory tanks, it doesn't matter if you are using a db or file based system, you have the same problem to fix. So that angle doesn't really even matter for purposes of comparison?