So do I. From Project Xanadu to the BeOS to the WinFS it has been a recurring idea in computing and for a good reason, I think. However, as far I am aware no popular implementation of it for Linux, the BSDs, Windows or OS X exists.
In particular, I have long wanted to implement a tag-based file system. Tagging should be easier to implement than a full-on DB-as-FS and, importantly, it would be easier to interop with existing file systems and tools that talk to them.
My design ideas for it so far are as follows:
You can map each tag to a directory at the tagging file system's mount point. Each of these N directories would then contain N-1 for each of the remaining tags to allow you to select files that have two or more tags. For example, the files with the tags "a" and "b" would be accessible through /tagfs/a, /tagfs/b, /tagfs/a/b and /tagfs/b/a.
In contrast to a DBFS accessed through, say, "/dbfs/SELECT * FROM .../" it would be possible to use "ls" to get the list of all the tags, to apply the POSIX permission model in a way that made sense and suchlike. E.g., the permissions of /tagfs/a/b/c could be an intersection of those for "a", "b" and "c".
One problem with this approach is in how ordinary (non-tag) directories would be interact with the directories that represent your tags. Not distinguishing them for the user would create a potential for confusing misfiling errors and data loss on deletion. Distinguishing them by giving the tag directories special names (e.g., ones that begin with a sigil) or permissions would limit the system's power. Extended attributes are not easy to see visualize in most GUIs, etc.
So do I. From Project Xanadu to the BeOS to the WinFS it has been a recurring idea in computing and for a good reason, I think. However, as far I am aware no popular implementation of it for Linux, the BSDs, Windows or OS X exists.
In particular, I have long wanted to implement a tag-based file system. Tagging should be easier to implement than a full-on DB-as-FS and, importantly, it would be easier to interop with existing file systems and tools that talk to them.
My design ideas for it so far are as follows:
You can map each tag to a directory at the tagging file system's mount point. Each of these N directories would then contain N-1 for each of the remaining tags to allow you to select files that have two or more tags. For example, the files with the tags "a" and "b" would be accessible through /tagfs/a, /tagfs/b, /tagfs/a/b and /tagfs/b/a.
In contrast to a DBFS accessed through, say, "/dbfs/SELECT * FROM .../" it would be possible to use "ls" to get the list of all the tags, to apply the POSIX permission model in a way that made sense and suchlike. E.g., the permissions of /tagfs/a/b/c could be an intersection of those for "a", "b" and "c".
One problem with this approach is in how ordinary (non-tag) directories would be interact with the directories that represent your tags. Not distinguishing them for the user would create a potential for confusing misfiling errors and data loss on deletion. Distinguishing them by giving the tag directories special names (e.g., ones that begin with a sigil) or permissions would limit the system's power. Extended attributes are not easy to see visualize in most GUIs, etc.