A mind less ordinary » Insight (semantic filesystem)

A content-based file manager

Dave — Thu, 04 Jun 2009 22:12:38 +0000

I’ve been thinking recently about Insight again, and I’ve been considering part of the problem with naming and uniqueness.

Names in a traditional file system are made unique based on a full path to the file, but most people think of a file name as just the final component. This would then cause a problem with the move to Insight, as a file could appear in multiple directories, and its only distinguishing feature would be the final component of its path. This is counter-intuitive and can cause all sorts of problems.

Consider makefiles, for example. They rely on a standard named file (Makefile) appearing at various levels in the hierarchy in order to work. Obviously, you would want different makefiles at different levels and in different projects, but Insight as it stands has no way to handle this.

I then started thinking about what makes a file unique. In the end, I came up with two things: name and content. This covers the makefile case (same name, different content) as well as the backup case (same content, different name). It then occurred to me that, in the general case, all you need to distinguish a file is its content, and then actually finding it can all be left up to metadata.

If files are then thought of as containers for data that happen to have a unique internal identifier (which never needs to be exposed to the user, although it can be accessed as, say, the file’s inode number) then the idea of a content-based file manager comes into play. These examples work best with visual media, particularly images, but there is no reason in principle that this could not be extended.

Imagine searching for a file. You know it’s a photo, but you have a large collection of them. With a digital camera and a large-capacity memory card, who needs to ever delete a photo? We’ll assume that you’ve dilligently tagged the photos with metadata as you’ve imported them from the camera, through some easy batch process.

On the tagging point: a lot can be taken from the metadata stored by the camera (date/time, resolution, orientation, black and white/colour, perhaps GPS co-ordinates) and with the right tools, more can be inferred (auto-tagging faces, buildings, perhaps recognising common events like football matches, converting GPS co-ordinates to places, …). As time goes on, people will need to do less and less manual tagging.

Anyway, back to the file manager. You know you are after a picture or a set of pictures. Normal thought processes will probably follow a path similar to: “Yeah, I wanted to show dad those photos from that holiday in Paris that we had two months ago. I think he’d particularly like the ones we got of the Louvre, as well as the ones with me in, of course.” I’ve highlighted various key words that can be translated directly to metadata searches. Notice how these all involve a narrowing down of the query.

To convert these to filters, we then have:

type: photo
holiday
location: Paris
date: two months ago
at least one of:
- location: Louvre
- person: Me

This could also be represented by a query:

type:photo AND holiday AND location:Paris AND date:-2m
AND (location:Louvre OR person:me)

Breaking it down in this way feels fairly technical and wordy, however. I’d much prefer a visual view.

Imagine a black field, speckled with points of light representing your photos:

You filter by “holiday”, and (because it learns based on previous searches) it then groups by location. The ones which have been filtered out fade into nothing, and the photos group into labelled blobs and enlarge slightly:

You filter by date, and as you drag the slider, irrelevant items fade away and relevant ones enlarge:

Then you add the final filters and set the photos up for viewing, perhaps as a slideshow… and you’re done!

Pretty neat, I think.

Insight: Where am I now, and where next?

Dave — Thu, 05 Jun 2008 23:18:29 +0000

So I’ve been in Deep Coding Mode™ for quite a while. What have I got to show for it?

Well, the short answer is that Insight is now a functioning file system… for a given definition of “functioning”.

As of this morning:

It can successfully import files from the rest of the hierarchy
Tags (i.e. directories) can be created and removed at any level.
Tags appear and disappear more or less as you expect (i.e. if you already have a tag in your path, it won’t show up in listings again).
Tags that are synonyms will show up as symbolic links to the actual target tag (but currently do not obey the rule in the point above, i.e. if their target has been used in the path, they may still appear).

So far, so good. Now for the limitations:

Files cannot currently be opened, read from, written to, or deleted.
Files must be imported in a strange manner: as absolute symbolic links. They then show up as regular files, although they are actually just links to the originals elsewhere in the filesystem.
Tags cannot be assigned to files (or removed from them)
Files can therefore only be imported at the root level
Queries have no effect on file listing, and so listings just show files in limbo
Of course, there is no subcategory union either.

But I am working on all of these things. At the moment, the main thing is sorting out the internal inode lists. Once those are done, then it should be quite straightforward to do tag assignment/removal and import directly into tags. Plan of action, therefore:

Implement inode insertion/deletion
Implement inode set functions (intersection, union, difference)
Re-implement query tree builder from path. Currently only deals with building a basic conjunctive query tree and assumes that all components are tags. Should:
- Take a path
- Canonicalise it
- Check path components (left-to-right) to ensure tags exist
- If last part is an incomplete tag, treat appropriately
- If last part is a complete tag, then fine
- If last part does not resolve as a tag, then hash it and see if it translates to a known inode
- If not, or if any tags in path do not exist, then path is invalid
- If it is a valid inode, then add QUERY_IS_INODE node to tree
- Otherwise return query tree
Implement query processing:
- Given input set of inodes, produce an output set at each node of the query tree.
- In trivial case with top-level IS_ANY node, output set is the set of limbo inodes, with internal negation flag set to false
- With an IS node, the output set is the recursive union of the inodes belonging to that tag and its subtags, with internal negation flag set to false
- With an IS_NOSUB node, the output set is the set of inodes belonging tag, with internal negation flag set to false
- With an IS_INODE node, the output set contains a single element: the inode.
- With an IS_NOT node with a subquery, the output set is identical to the subquery resultset, with an internal negation flag inverted
- With an IS_NOT node with a tag, the output set is the same as for an IS node, with an internal negation flag set to true
- An AND node output depends on the negation flags of its subqueries:
  - Both false: output is the set intersection of its subqueries, with negation flag clear
  - Both true: output is union of subqueries, with negation flag set
  - Otherwise: output is set difference, with the negation-true set removed from the negation-false set, and the negation flag cleared
- An OR node output depends on the negation flags of its subqueries:
  - Both false: output is union of subquery results, with negation flag clear
  - Both true: output is intersection of subquery results, with negation flag set
  - Otherwise: output is ???
- Probably very likely to be an error if the negation flag is found to be set at the top level.
- Also have to think about how to build a tree from a bracketed expression. But later. Much later.
Output of query processing is an inode set.
Maybe low-overhead query processing just to see if an inode would match the query?
Implement open/read/write as pass-through operations on the inode symlink targets.
Implement symlinking directories as creating synonyms.
Add LOTS of checks.
Note: also have to track inode reference count, so that when it gets to zero the inode is added to the limbo list. Once removed from there, it is removed from the filesystem completely.

These should be quite straightforward to do (I hope), especially as I know more or less exactly what I’m doing. Deadlines are closing in, however, and I have a report and presentation and demo to write yet. Hopefully I can get much of this done by Tuesday, then can spend the day doing bits of my report.

I must say that I do love developing this. It’s just so amazing to be developing a file system and see it work!