Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TMSU: a tool born out of frustration with the hierarchical nature of filesystems

tmsu.org

Post reply on HN
Print view View original

101–110 of 131 posts

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#101

Post by anabis »

blakeyrat wrote: post #62
kpil wrote: post #18

Earlier quoted context omitted.

I agree. I actually like the hierarchical organisation, and I don't like the 10 year usability trend, particularly driven by Microsofts attempts to patch over their horrid structure with even worse workarounds. The solution to learning my mother were to find her documents is not hiding the place 15 levels deep and having 10 symlinks to it. Fast, unobtrusive indexing and a good structure is all that is needed. Humans…

> Humans organise and memorise things in hierarchies, Humans also track a lot of things based on spatial memory, which no OS since Mac Classic has even tried to make use of, which is a shame.

Project Xanadu had something like that. Of course, it is barely working.

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#102

Post by e12e »

> TMSU does not alter your files in any way: they remain unchanged on disk, or on the network, wherever your put them. TMSU maintains its own database and you simply gain an additional view, which you can mount where you like, based upon the tags you set up.

I'm not so sure this is a great design decision. Now your tags are only in your sqlite file, and you'll have to work extra hard to get a copy of the relevant tags when you backup/copy etc.

I think storing tags in extended attributes[x], and possibly a separate utility that maintains and index (hopefully shouldn't be needed just for the tags, but might help with a) exposing file-level tags (like ID3, exif, file-type (magic number) etc), and b) allow for automatic organization based on full text and other content-based indexing.

It appears, on a * nix system, the only major reason to stay away from extended attributes (apart from the limit on size of tag data) is NFS. But samba should (AFAIK) work fine with extended attributes.

As far as I can gather, Gnome Beagle is dead, and Gnome Tracker[t] has taken its place. But it's not crystal clear if Tracker will index tags placed in files' extended attributes or not. If I understand correctly, Tracker's own tagging utility, will only place/edit tags in the Tracker database/index. But the indexers will certainly honour file-level tags for some files.

I don't really use full Desktop environments, but some kind of system with inotify support, and a Xapian or similar back-end (like Tracker), does seem like a good idea. It would certainly be nice to see such a system implemented in Go, but I think an architecture along the lines of Tracker is probably worth keeping: A database daemon, an indexer and a set of query/view tools (I'm not a fan of the centralized tag database, though).

Another alternative to Tracker would be Recoll:

http://www.lesbonscomptes.com/recoll/index.html

[t] https://github.com/GNOME/tracker

[x] http://www.lesbonscomptes.com/pages/extattrs.html

Btw, for editing/automating ID3 tags, I recommend "Ex Falso", the tag-editor for Quod Libet (which is an audio player): http://quodlibet.readthedocs.io/en/latest/

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#103

Post by cvwright »

seagreen wrote: post #21

A great idea! I think tags are definitely a better way to organize most personal data than trees. Also I like that they describe what data they actually change on your computer right on the homepage: "TMSU does not alter your files in any way: they remain unchanged on disk, or on the network, wherever you put them. TMSU maintains its own database and you simply gain an additional view, which you can mount, based upon…

Couldn't they just create a hardlink in a private, hidden directory that they control, and then symlink to that?

Then, it's OK if the original file gets renamed or moved, as long as it stays on the same FS. You still have your hardlink, and so your symlink still works.

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#104

Post by zaphar »

e12e wrote: post #96
zaphar wrote: post #87

Earlier quoted context omitted.

I don't really need semantic search. Full text search covers 99.9% of my needs.

Your videos, music and pictures must be rather boring, if you can index them with OCR... ;-)

This is probably explained best by the fact that I don't really store videos, and My Music and Images are all in the cloud.

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#105

Post by RubyPinch »

deprave wrote: post #11

UI nitpicking: These: $ tmsu tag summer.mp3 music big-jazz mp3 $ tmsu tag --tags "music mp3" foo.mp3 bar.mp3 $ tmsu tag spring.mp3 year=2003 Are confusing. Very non-Unix. They should be: $ tmsu tag music,mp3,year=2003 summer.mp3

I have to ask, how are they non-unix?

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#106

Post by Mister_Snuggles »

JadeNB wrote: post #95
Mister_Snuggles wrote: post #39

Stuff like this is cool, but it really points out just how poor the filesystem is for organizing certain types of data. The "Why does TMSU not detect file moves and renames?" question in the FAQ really highlights how this isn't helped along by the filesystem at all. One comment mentioned BFS, which had some really cool stuff. There's an Ars Technica article that touches on some of it[0]. The secret to BFS, in my mind…

> Unless the metadata becomes a first class citizen in the filesystem, any attempts to layer it on top will have problems. Remember when it seemed like Mac OS might give us a modern era of rampant metadata ( http://arstechnica.com/apple/2005/04/macosx-10-4/6 )? Ah, those were the days.

Yup.

MacOS does an OK job of helping the user find things with Spotlight, but it's not a full metadata system like BFS had.

Mail.app, for example, keeps each message in a separate file[0] (and probably has a cache or separate database of this to make displaying mailboxes quicker). This makes it easy for Spotlight to index, but all of the stuff that you'd think of as metadata is actually just regular data inside the .emlx file.

If Apple made a huge effort to start treating the metadata (assuming the infrastructure described in the Ars Technica article still exists) as a first class citizen and using it like BeOS did, maybe we can get there. This would be a drastic rethink though. It feels like files, in some ways, are becoming second-class citizens in the Mac world. Photos, for example, are managed in the Photos app - you do not go into the filesystem and organize your photos.

One big problem with filesystem metadata is how do you transfer it? The Ars article showed a sidecar file (._filename) being created when the file was copied to a non-HFS volume. Now the metadata is detached from the file and we're back to the same problem.

[0] http://mike.laiosa.org/2009/03/01/emlx.html

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#107

Post by DougWebb »

ori_b wrote: post #79
alpyne wrote: post #32

Earlier quoted context omitted.

I'd argue that tags provide a more graph-like structure, of which a hierarchy (tree)[1] is just a subset. Symlinks provide an "escape-hatch" to hierarchical systems allowing objects to appear to be in more than one directory. [1] https://en.wikipedia.org/wiki/Tree_(graph_theory)

How so? Unless you can tag tags, you can't represent a tree with them. If you can tag tags, you get an arbitrary graph, with all the problems that represents. I don't think I've seen tagging systems that let me tag tags out in the wild.

The 'path' in the tree can be represented as a tag. It's a simplistic way to go, but you can get pretty far with it to emulate a folder structure using tags.

Re: TMSU: a tool born out of frustration with the hierarchical nature of filesystems

#108

Post by chongli »

therein wrote: post #97
blakeyrat wrote: post #62

Earlier quoted context omitted.

> Humans organise and memorise things in hierarchies, Humans also track a lot of things based on spatial memory, which no OS since Mac Classic has even tried to make use of, which is a shame.

How did Mac Classic make use of that?

In Mac Classic each folder you opened created a new window which remembered all of its settings for size, position on screen, scroll position, icon size/layout, etc. This window is an explicit and exclusive representation of that particular folder and attempting to open the same folder again does not create a new window, it simply shifts the focus to the already-open window. The change in Mac OS X towards a browser for navigating the filesystem hierarchy caused an active debate over spatial[0] vs. navigation (or browser)[1] file managers.

[0] https://en.wikipedia.org/wiki/Spatial_file_manager

[1] https://en.wikipedia.org/wiki/File_manager#Navigational_file...

Post reply on HN