Non-hierarchical file system (tags+attributes?)

1

Hey all,

So I was wondering if any of the Haiku devs have considered a tag based approach to the file system. I was just thinking that, since Haiku already uses a database-like file system, why not take it all the way?

The folder based approach that we’re used to is a leftover from the days of physical filing cabinets, and it’s restrictive in many aspects. It’s also very cumbersome to browse through, forcing you to crawl through endlessly nested folders to reach what you’re looking for. (Of course Search… helps, but only when you know what you’re looking for)

Basically, what I propose is to replace ALL folder based navigation with a tag based equivalent. Such a file system, I think, would be surprisingly easy to get used to, and infinitely more convenient both for organization and browsing.

If anyone is confused, I can elaborate why I think a tag based file system could accomplish anything a traditional file system can do, and more, even better. But I don’t want to poop out a wall of text for the OP, lol. Also, I’m aware this discussion is very hypothetical until R1 is finished.

3

An initial experiment could be done with the current query window (use the Desktop’s Find command to open one) and a custom attribute, perhaps called “tags”, attached to the files. Add the tags you want to the attribute on the files you are marking, perhaps separating multiple tag words by commas. Then do the Find on the tags attribute with the word you want to look for. The resulting window will show all matching files, and is live (if you add new files or change tags, the window contents automatically update). You can also use the file types preference tool to make the tags attribute publicly visible (or even editable), so you can see the tags as a column in the file listing windows.

All that’s missing is a multi-select combo box to choose tags when editing or searching. And clicking on a tag in a file listing to start a new search window for it. Also missing is better support for array attributes, rather than storing tags as a comma separated string.

4

Hierarchical filesystems are a holdover? Lord no. Non-hierarchical filesystems are what they had in the bad old days of the early mainframe OSes, or in CP/M when the early micros didn’t have the RAM to handle subdirectories. We’ve spent years getting away from flat filesystems.

Tags and attributes are nifty stuff, no question about that. But simpy because you can sort-of implement filesystem hierarchy that way doesn’t mean it’s a good idea. In a hierarchical filesystem, all that’s required to get the listing of a folder is to run through the directory that’s stored on the disk. If you wanted to get the listing of a notional “folder” in a database filesystem, you’d have to run a query on the entire filesystem to check which files have their “owner folder” attribute set to match the current directory - and with thousands or millions of files on a single disk, that would be ridiculously slow.

You could speed it up by creating an index for the “folder,” but then - guess what? - you’ve just reinvented the directory. There’s just no conceivable reason to do that. Some tools are good for some things; other tools are good for something else. Trying to wrench a tool into serving a purpose it wasn’t intended for when you have a perfectly good tool that was explicitly designed for the job is a fool’s errand.

1 Like
5

I don’t know how those systems worked, but I’d bet they weren’t using tags for navigation. In fact, I wouldn’t be surprised if the only means of identification back then was a file name. You seem to be the authority on this, maybe you could enlighten me. Regardless, I’m positive that the hierarchical file system is an outdated way to organize your files.

If you’ll recall, I suggested a non-hierarchical file system.

[quote=agmsmith]An initial experiment could be done with the current query window (use the Desktop’s Find command to open one) and a custom attribute, perhaps called “tags”, attached to the files. Add the tags you want to the attribute on the files you are marking, perhaps separating multiple tag words by commas. Then do the Find on the tags attribute with the word you want to look for. The resulting window will show all matching files, and is live (if you add new files or change tags, the window contents automatically update). You can also use the file types preference tool to make the tags attribute publicly visible (or even editable), so you can see the tags as a column in the file listing windows.

All that’s missing is a multi-select combo box to choose tags when editing or searching. And clicking on a tag in a file listing to start a new search window for it. Also missing is better support for array attributes, rather than storing tags as a comma separated string.[/quote]

This seems like a good starting point. Of course, moving over to a completely tag-based system would have much more far-reaching implications for the interface. Maybe I should sketch a mockup for how I think the Finder would look/work in such an environment.

There is a gripe I have with tags, and that is their relation to attributes. Every time I think up a metadata based file system, these things seem to conflict with each other. As far as I’m concerned, either of these could do the job of the other, but they each have their own benefits and flaws. Here are the respective syntaxes for a particular file:

Tags

[Unique pointer to the file itself]
Song
Bohemian Rhapsody
A Night at the Opera
Queen
31
10
1975
Rock

Attributes (Attribute:Value)

Pointer:[Unique pointer to the file itself]
File type:Song
Title:Bohemian Rhapsody
Album:A Night at the Opera
Artist:Queen
Day released:31
Month released:10
Year released:1975
Genre:Rock

So tags are essentially values without attributes… Clearly, the attribute:value pair is much more semantic.

The values from an attribute based file system could be used just like tags for browsing. Such a system would also allow arrangement by any attribute, just as always. On the other hand, a tag may be easier to just slap on a file for the typical user, especially in non-standard cases. I guess the question here is, should values always be tied to an attribute-value pair or be a bit more lenient?

If I’m going too fast here, just tell me, lol. I’m developing the idea in my mind as I go, here.

6

Ok, so when I type ls in a Terminal, what files are listed? Do I have to adjust all my scripts? Will all my hard work be thrown away just to get rid of directories?

I think the benefits of a directory, sub directory system far outweigh the this idea that it is out dated.

7

Might be interesting to conjure up someone who can clearly remember early releases of BeOS. DR8 for sure, possibly one or two releases after that, the filesystem was strongly database oriented. Somewhere before R3, that was replaced or reengineered with more of a hierarchical orientation. I honestly can hardly remember a thing about it … I don’t think the differences would have been conspicuous to the ordinary user, it was more of a question of APIs, but someone else might remember better.

Organization is a big deal, increasingly as we get more data coming in and more room to store it. Certainly worth thinking about. If there’s an idea worth pursuing, it ought to be possible to come up with example scenarios that demonstrate how it could do better.

8

A hierarchical file system is based on the B+ data structure, which, is provably, one of the most efficient mechanisms for searching and sorting files. What does that means? It means that after you start loading up your file system with 10,000’s of files or more, it still runs quickly.

Now that doesn’t mean you can’t put a tag based GUI or command line shell on top of BFS. Or on top of NTFS, or whatever. In fact it has been done and those shells are very cool.

So maybe you could refine your idea a little more and report back on your ideas?

Personally I think Haiku would be awesome for prototyping stuff like this.

9

I have been thinking about what could replace directories in the file-system.

I think attributes with cached queries and the Desktop are the ingredients.

Imagine a lawyer’s desk. There is a stack of folders to the side, and all the forms and bs that he is working on in front of him. Then, he has a meeting with a client, so he has to clear his desk, and present the new scenario of the desk to work with the client.

With Haiku, what if the Desktop were empty of files by default. Then, you go to the Haiku Menu → Find… and issue a query by attribute (or tag I guess) for that specific client’s name. Then, those results would appear on the Desktop. Perhaps they appear as a stack, which upon clicking would spread out… but I think the location of the files is important and should be remembered (perhaps in the cached query file).

This completely solves the lawyers problem, losing directories. Now, what about saving a new file. I think the filename is still important. When you go to save a file, you are presented with a form which has all the attributes presented in a nice GUI, and everything is optional. This is a bit different than tags. Maybe give the user the ability to design the form with drag 'n drop + delete and add attributes. All that information + Filename goes into the filesystem which is a database. So there is no directory location anymore.

What about source files, and including them. Maybe the terminal still knows about directories. Maybe programs have default directories, and everything I described above is just a new Desktop paradigm.

Another idea is having a dock of cached queries there too on every workspace. I think if you unload a query on a workspace, it should exist only on that workspace, not on all workspaces.

10

Uh… Why necropost an 11 year-old thread?

1 Like
12

Yes, seems like a bad idea. Let it rest at the bottom of the forum where it should be :slight_smile: