As I understand, files in Unix are all stored in a "flat" structure in the hard drive -- the file system is merely links from directories to other directories and eventually to leaves/nodes/files. Many hard links may point to the same file (but not the same directory/branch)

Has there been any approaches to this where there are essentially no folders at all -- all of the files are in one giant folder, and instead of folders you have tags? Your home directory might then not be files in folders but instead merely lists of tags/folders, where a file may be found in more than one?

And also some sort of software faculty to do more complicated tag queries, like filtering.

  • MS-DOS 2.0 introduced directories in March 1983. Mac OS 2.1 introduced proper directory support in September 1985 along with hard disk support. Unix systems have supported directories for I don't know how long, but DOS 2 directory support was based on the Unix pattern. Like @BruceEdiger points out, being able to organize files into directories is a pretty useful feature. It's much easier to make a well-performing file system where the number of files per directory is relatively small.
    – user
    Jun 28 '13 at 8:38
  • The reason we still have hierarchial filesystems as opposed to semantic filesystems is becasue hierarchies (trees) are faster to search than lists. A tag-based filesystem would often require multiple lists to be searched.
    – Zaz
    Sep 30 '14 at 21:06

It's true that file's data is "flat" on the actual disk drive. Most (all?) modern disk drives have "LBA" (Logical Block Addressing), which means that even to the kernel, a disk is a great big line of blocks. The blocks containing a file's data might be interrupted, because inodes, etc, get spaced out throughout the line of disk blocks. So "flat" is a bit deceptive as a description.

It's also true that the "hierarchy" part is just a fiction: folders (better referred to as "directories") and their membership get their arrangement from the kernel "making it so" by reading file names and matching inode numbers from a directory's data.

But a hierarchical arrangement of data is pretty useful. As long ago as 1991, people were arguing about that, and getting refuted soundly. See Brent Welch's The File System Belongs In The Kernel for a better argument than I can compose.

I also feel compelled to note that Microsoft has embarked on a file-system-as-database at least twice in the last 20 years, and abandonded it both times, but maybe I'm interpreting what Google says incorrectly.


There are FUSE filesystems that provide tag or query-based views of an existing hierarchical filesystem, but none that I know of that let you work entirely in the non-hierarchical view.

Tagfs provides a tag-based view, but you need to set up the tags manually. The same goes for the more mature Tagsistant. QueryFS has a proof-of-concept for accessing files via arbitrary database queries.

Other entries in the FUSE filesystems list may interest you. (Warning: this list is neither comprehensive nor up-to-date.)


You can already do that today: More or less all Linux file systems support extended attributes. You can use EAs for your tags. But: Probably no file system is optimized for such a flat structure thus it may become rather slow. And, of course, it is not enough to have a file system which supports this: You need an application which supports this, too.

In KDE (and probably other desktop environments, too) you can tag files with key words. But they seem not to be stored in EAs. I don't know how they do that, probably with a separate database engine as this is a classic database task.


BeOS was one of the more promising experiments in desktop operating systems, although it really wasn't a Unix variant. Or a commercial success. But it certainly had some interesting ideas, one of which was the BeOS file system, BFS.

BFS did not completely abandon a hierarchical structure, which is pretty useful organizationally, but it augmented it with a highly flexible system of attributes, with indexes maintained as B+-trees, and hooks making it possible to define live (i.e. constantly maintained) queries, which could be used to impose alternative organizational structures.

I think there have been BFS reimplementations for Linux.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.