Author: Telcontar
Basis: StevMX
Category: System proposals, File system
Status: Experimental
The tagged file system is a proposal by StevMX to replace the conventional system of a folder hierarchy with a flat system of tags similar to how Flickr operates. This will be supplemented with content indexing to provide rapid access to any file without worrying where the file was saved or even what the file may have been called or tagged. This system will exhibit a degree of multi-dimensional access in that files can simultaneously exist in multiple categories, although no direct hierarchy as such will be supported.
Files under the Tagged File System will be categorised by attaching one or more "tags", or name attributes, to each file, in a manner resemblant of content categorisation on the Web. Tag names will include the likes of "Project 2006", "Downloads" and "Summer vacation". However, unlike folder-based categorisation, each tag attached to a file is not restrictive and the file can appear in multiple folder views according to which tags are being used to filter files.
For convenience, a version of folders will continue to exist, known as "bookmark folders". A bookmark folder is a file used to remember a specific set of tags by which you wish to access files again in the future. When opened, it will present a folder view of all files which match the given tags.
Files will be able to be filtered with attributes other than user-provided tags. File creation, modification and access dates will be provided along with meta-attributes such as words contained in the content of the file. Meta-tags such as "today", "yesterday", "this week" and "this month" will be provided to narrow down content. Existing file metadata such as ID3 tags and EXIF data could be integrated into the TFS by caching the data into the the metadata database or the content index. Treating such data directly as tags would be quite beneficial as you could for example list all music by an artist simply using the artist's name as a tag.
Compliant software would also provide extra, automatic tags to help the user find files later regardless of how they were tagged. A file received, for example, from an ICQ user might be tagged with the supplementary tags of "Download", "ICQ", "Telcontar" and "108315622" (the nickname and ICQ UIN of the provider of the file).
TFS does not directly understand or permit hierarchical paths, as the concept does not directly exist. For example, given two tags "A" and "B", the path /A/B/ filters the intersection of tags "A" and "B". There will be files tagged with "B" which do not appear in that grouping. Intersectory paths in TFS are also commutative, such that /B/A/ would be a direct equivalent. Thus, running an Internet server from TFS would present some confusion as paths would no longer exist in the expected manner. It would also confound the use of a command-line shell somewhat. Paths created by the system could frequently become confusing; for example, a file placed onto the desktop may be stated by the system to appear at the path /Summer vacation/Desktop/, which is correct -- because paths are commutative -- but the desktop is considered a top-level container in hierarchy. This would also conflict with an assertion by a command-line user that the file exists at /Desktop/Summer vacation/.
Further, the lack of hierarchy would make it impossible to copy a large number of files to a removable medium and have them be ordered in any reasonable means on a different platform, since the only possible order that could be achieved is a flat folder containing all the files. Care must also be taken to keep the tags and the files correctly associated on hierarchical file systems to permit transfer from one PC to another via a FAT16 USB stick to work without losing all the file metadata by which files are categorised.
One must also be aware of the issue of reference collisions. A file called "foo" tagged with "A" will co-exist in the same flat file store as a file called "foo" tagged with "B". Normally, "A" and "B" would act as primary keys in keeping the two files distinct, but the union path /A&B/ now contains two identically named files with no way to differentiate them programmatically or at the command line. When the files are to be stored on another file system, duplicate filenames need to be automatically mapped to different names, transparently to TFS if possible.
TFS will be required to replace the existing file system access UI modules with ones suitable for a system without hierarchy. The new modules will be responsible for recalling existing tags and creating new tags, as well as formulating disc views before committing a new file to that selection of tags.
The implementation of TFS can be approached from several angles. It could be assumed to be the single file system design on which the entire operating system runs, or it could be assumed to simply be an alternative in use by a particular user. There are too many questions presently posed to ascertain whether the OS as a whole could run from such a file system, but it is certainly possible to grant a given user or class of user accounts this file system for their home folder and in fact their entire and only view of the disc.
As such, to grant the file system to one or more users on the system, it could be presented as a layer on top of an existing hierarchical file system at the root, or embedded within a local file system store.
TFS can be implemented as a thin layer atop an existing hierarchical file system. This would involve all the files being stored in a single folder and mapped to a database of tags. StevMX expressed a concern that other users accessing the files via the normal file system could desynchronise the files and the tag database, but this could be mostly avoided by using UIDs in the main file system such that moving and renaming files would not disrupt the references stored within the tags database and content index.
It would also be possible in theory to store local copies of the tags in the standard metadata store associated with files in hierarchical file systems should a file need to be stored for some period on a different Cy/VOS file system.
TFS could also be implemented as a local file system store in order to allow it to make use of a completely separate disc storage layout without going via the regular file system.