You may wonder how Tagsistant refers to the files it is managing. Well, whether you care or not, knowing how this happens is something very useful. Behind the scenes Tagsistant assigns to each file a unique number, called a Tagsistant inode. The word inode comes from the filesystem lingo and is used by Tagsistant in a rather liberal way. You can just think to it as an ID or a serial number, if this sounds more familiar. Just remember that each file has its own.

Now let's take a look inside the archive/ directory:

$ ls ~/myfiles/archive/
0 1 2 3 4 5 6 7 8 9

The archive/ directory is where your files are kept. Starting from release 0.8, Tagsistant organizes them in a hierarchy of subdirectories, placing each file in a specific directory chosen by reverting its inode and taking the first digits (by default the first three, but that can be configured). Let's see an example: a file with inode 1923 will be placed in archive/3/2/9/, because 3291 is the reverse of 1923 and only the first three digits are considered. In our examples we have a small amount of files and the situation is something like:

archive/1/1___first_contact.avi
archive/2/2___the_wrath_of_khan.avi
archive/3/3___the_empire_strikes_back.avi

When inodes are shorter than three digits, the hierarchy ends before. Here "first_contact.avi" has inode 1, "the_wrath_of_khan.avi" has inode 2 and so on.

You may be wondering why this is something you should know. In fact usually you don't care about inodes since you can see them just inside the archive/ directory, which you are not supposing to visit very often, being the big part of the game played inside store/ and tags/. This is correct, but with one important exception.

If two different files (this means two files with different contents), copied inside two or more different tags, have the same name (such as avatar.jpg), Tagsistant will apply the inode in front of them when it have to list both as the result of a search operation, like in:

$ cp ~/myblog/avatar.jpg ~/myfiles/store/blog/@
$ cp ~/movies/covers/avatar.jpg ~/myfiles/store/pictures/@
$ ls ~/myfiles/store/blog/+/pictures/@
... 231___avatar.jpg ... 862___avatar.jpg ...

This is the only way Tagsistant could let you distinguish two different files with the same name when both are returned by a query. If no filename overlaps, Tagsistant will avoid putting the inode:

$ ls ~/myfiles/store/blog/@
... avatar.jpg ...
$ ls ~/myfiles/store/pictures/@
... avatar.jpg ...

The two avatar.jpg files are not the same, but since there's no ambiguity, there's no need to show their inode.