Hacker News Reader

Comment by spicybright | Hacker News Reader

I've been hearing this for years, but I've never had the mental model for it. Maybe I just have to try it out.

There's a very neat project (can't remember the name, and some details below may be wrong,) that mounts a FUSE filesystem that uses only tags.

Paths have identical syntax to hierarchical ones, only each segment of a path is a tag.

so `/document/taxes/2020` would return a collection of files, but you could also write `/taxes/2020/document` and it would mean the same thing.

The advantage is you can use standard unix tools like ls, mv, cp, etc. as well as R/W using standard programs (like how you'd export an image.)

I'm sure there's edge cases to it, but I always found the idea very neat. Anyone remember what I'm talking about?

View on HN

The downside of folders is trying to figure out where things belong in the hierarchy, or trying to update that hierarchy to a new standard.

The downside of tagging is you still need to establish conventions to ensure things can be found again, but enforcement of your conventions is harder.

Exploring, learning, and using an unfamiliar folder hierarchy is easier than exploring, learning, and using an unfamiliar tagging methodology.

But manually searching for something in somebody else's tagged data is easier than manually searching for something in somebody else's folders.

It seems that for any DAG, a hierarchy could be derived that would minimized either the number of soft-links, or a weighted score of how many contained files are in a soft-linked path.

And, similar to how a sugiyama graph automatically redraws when an edge is added or removed, a filesystem hierarchy could be automatically restructured to minimize the above scores when files are added or removed from the various folders.

> The downside of folders is trying to figure out where things belong in the hierarchy, or trying to update that hierarchy to a new standard.

That's why I stick to Documents/{folder1..folder∞} and folders don't have hierarchical sub folders, just contextual folders. Eg: Documents/taxes 2021/{invoices, stuff}, Documents/taxes 2021/, Documents/Cthulluh Roleplaying/{pdf files of characters}, Documents/Covid vaccination certificates,

Yes, it's messy but I don't have the mental burden of a holding a tree in my head or a tagging system.

I try not to go more than three folders deep (starting from ~). I don't mind a lot of files in a folder, search helps me with that.

My current setup is: Documents, owncloud, Downloads, Dev, Media and tmp. No desktop. At work I have an additional git folder.

> I've never had the mental model for it.

This is one way to think about the hybrid model of folders + tags that is currently available:

1. Folders tell you where the file is stored.

2. Tags tell you what is the file.

So basically use the Tags to add more data (metadata) about your files, so that if you forget where the file is, you can still search for it by what is in it. This also slightly helps in easing the burden of trying to figure out where to store a file (e.g. "Do I put a home video in my 'Videos' folder or my 'Personal' folder?" - if you tag it properly, you can put it in either, as you can use the tags to figure out where the video is later).

Examples:

1. In Documents folder - "mom-2020.xls" (tags => docs, tax, finance, mom, unfiled).

2. In Videos folder - "newyear bash.mp4" (tags => video, family, 2021, home).

Don't think I ever had it explained this clearly to me lol. Thank you! I run Mac os so I might give tagging a try now

I'm the author of Supertag, which is what you might be talking about. https://github.com/amoffat/supertag

> I've been hearing this for years, but I've never had the mental model for it. Maybe I just have to try it out.

Gmail uses tags rather than folders, nice easy way to have a play if you've already got a google account.

Conceptually, I think of it as basically being able to have lots of different hierarchical folder structures applied to a set of objects at the same time. Or to flip it round, a normal folder structure is like using tags but where you are limited to one tag (the folder that holds the object) per object.

Not exactly. In Gmail, tags are hierarchical.

So, if I have a tag called 'projects', and another tag called 'newproject', the overall tag is 'projects-newproject'.

If I try to see everything under 'projects', it'll only show me the ones tagged 'projects' directly, not the ones under 'newproject'.

This is only if you use it hierarchically. No one prevents you from having a tag projects and another tag newproject. Your emails just have both tags assigned and you are good to go

Sure, but GP's point (and it's something that annoyed me in Fastmail too) is that if you do have an 'hierarchical tag' - which could be in addition to unrelated tags - you don't get the '<sub-tag> is a <super-tag>' that you might expect.

The tags themselves end up in an hierarchy without it affecting the tagged contents.

From a document perspective, yes, you're correct.

From a tagest perspective, and the discovery affordances, there is a significant difference.

Hierarchical tagsets allow you to navigate via tags, affording document discovery by that mechanism.

That becomes more significant as you're working with a larger, richer, and more structured tagset.

I think what you're seeing is the opposite: tags aren't hierarchical. Tags can be organized hierarchically, for organizational purposes, and you can use rules to ensure that everything tagged "projects-FOO" is also tagged "projects", but the tags as they apply to tagged objects aren't hierarchical.

10 years ago I was prototyping something very similar for Windows.

If I recall, CBFS and Dokan were the closest things you had to FUSE on Windows back then. Alternatively considered emulating a network drive. Like you pointed out, it had to be transparent to your existing software's Open / Save dialogs (although there was some effort to hook the standard ones to give users a place to apply tags when saving).

We've been stuck in the same old directory paradigm for a long time. There are some use cases where the traditional hierarchical approach is desirable (e.g. when you need to "visit" a set of files exactly once, like to browse through a folder to clean it up, enumerate for backup, calculate sizes, etc). But it's a constraint when a file belongs in more than one place.

There's a Windows component for this now - Projected Filesystem (projfs).

You are probaly thinking of https://github.com/cfagiani/cotfs which allows ln but not mv or cp.

Ah, that's right. Thank you for the link!

My favourite file organization hack is to have a "scratch" folder containing everything that I can lose with no problem. Stuff only comes out of the scratch folder if I know I can't redownload it again and I might need it.

This way I can just wipe the whole scratch folder whenever I want, and there are much less files I actually need to organize.

Similar but mine is ~/tmp and I have a cron job that deletes any files/folders over 30 days old.

Oh man, that's smart. Would you mind sharing that script?

You could use something like this:

   find /tmp -type f -mtime +30 -delete

This is what I use my desktop as.

At it's simplest, a filesystem can be thought of as a string key (small) to value (large blob) database.

Directories are just a method of breaking the collection into usefully small / specific subsets for humans (mostly) and computers (a secondary but important performance optimization).

There's no technical reason some form of Standard couldn't be added to, or on top of, a filesystem that added tags as an alternate view or foreign index against the data.

The holdup is that there isn't any single standard for adding or searching by tags. The current directory structure is the lowest common denominator and has existed for longer than many of us have been alive. Change is _hard_ and those file open/close dialogues and interface methods still have to work, and they can work, at least for limited numbers of tags or maybe by some addition / removal special path syntax... However then it's stupid hard for the humans. Hard for the use case the tags are supposed to simplify.

Maybe this change can be added to what everyone really needs: a set of GUI calls that work on all the platforms, that isn't writing a damned web-page and using a DLL-hell-bloat bundled web-browser to do the cross platform lifting. Something that can work across all the desktops (as a target) and maybe all the mobiles (as another target) and maybe tablets too (slightly different target, somewhere between).

I think the api that allows for more flexibility of implementation underneath is a hierarchical multi tag system with one root of the tag reserved for the existing filesystem, eg. "fs". Paths on /fs/dir/dir/file could serve as definitive storage reference and a way into the existing filesystem apis, while other tag systems can be imposed by the user in parallel trees of tags - all of which refer to the underlying fs tree under their implementations.

ahhh you mean like a json api for the browser!</sarcasm>

While I don't remember that specific project's name, I do remember that a lot of that was possible because files in a filesystem often aren't just some hierarchical folder structure. There is often a tree-like structure to be able to find a single file quickly amongst many files, but there was no technical reason why it wouldn't also support off-tree indexing based on tags.

I imagine one of the problems you'd run in to is mass updates since deleting a directory with many files in it below a single tree node is very much limited to that part of the filesystem's tree, but doing it with tags causes updates all over the place.

It does remind me of this more metadata-like FS: https://github.com/marook/tagfs

As well as the thing Apple does in Finder where it has a tag database and dynamic 'tag' directories where it shows you everything that was tagged with that tag. Then the search function would allow selecting files based on tags so you can do many-tag searches and only find the files that match all of them. I think that one is based on an in-filesystem metadata stream.

I think the article was about making it easier for users. It may not be easy anymore if they have to use directories AND tags. Or it may work, if the only files they normally tag are their documents.

Tags have a problem with names. How do you stop users from messing with files that belong to the OS or some application? Should we require that they all have the tags "OS" or "app" on them? Should binaries have the tag "binary"? What happens when the user tries to delete one app but chooses "tag 'app' and name startswith 'word'"? Should all application files named "word"-something from different applications be removed? Should the user have known to use a meta-query with "tag 'app' and tagname:startswith 'word'"?

I do see a lot of problems but of course some things would be easier.

At least that part of the puzzle is obvious:

Users should never touch system files nor have to look at them. I never want to see any asfawe.sdwae file ever again. Its like keeping power tools in the cup board or having screwdrivers in your utensils drawer. Its like keeping the manual in the washing machine. You open the door and instantly know it's a ridiculous idea.

The user should be able to do what he wants, anything should go, there should not be any bad moves besides deleting their own stuff, they should be able to simply delete everything. Make it a partition with a warning prompt.

Fuse tagging: TMSU. At tmsu.org.

(Collecting options) Another interesting project that's popped up before is Tagsistant: https://www.tagsistant.net/

This might work for documents but a difficulty I see is how you would handle system files. See, with documents it's fine to always return a collection of files, but for a system file say /etc/passwd, you want to make sure you get exactly (status quo guarantees at most which is almost but not quite as good) one file.

Just think of the endless possibilities of a node_modules folder replaced with some tags! /s

Sounds like a really bad idea for tools like mv and rm. Suddenly you have moved or deleted much more than you thought. Unless you support guids or similar also but end users are normally really bad at reading and writing those. It is very easy to mistake one guid for another.

https://github.com/kellen/urchinfs ?

Reply on news.ycombinator.com