Hacker News Reader

Comment by PaulHoule | Hacker News Reader

With symlinks (or hard links for that matter) you can have folders work like tags in a real filesystem.

That said, binary classification (object A is a member of class B, a function with a boolean truth value) is the basic concept in classification. That is, any classification can be represented correctly with binary classification.

There really are a few things where you assign something a category from a finite set (like a chess game was won by "White", "Black" or was a draw) but frequently when people build ontologies based the idea that "A is a member of one of this set of categories" they are going to screw it up.

View on HN

> With symlinks (or hard links for that matter) you can have folders work like tags in a real filesystem.

The word can is doing a lot of heavy lifting there.

Tagging system (at least the ones I've seen): enter the tags as autocompleted tokens in a single text entry. Possibly the system can autosuggest a number of tokens, possibly not, depending on your use case.

Symlinks-as-Tagging-System: I want to save a file called "foo.txt" and start editing it immediately. How do I enter the tags?

Presumably the same way you would enter tags in a regular program that has tags, except the datastructure would be stored as a disk file system. you dont necessarily have to manually run ln -s every time, the same way you dont have to run a sql insert to update a tumblr posts tags.

Yep, that's why when we built our PKM app[1], we decided to eschew folders not in favor of tags but in favor of nesting the notes (which we call cards) themselves. From there a card can be nested inside multiple other cards, which is an idea we stole from symlinks, which generally gives the benefit of a structured hierarchy while also giving the flexibility of tags. That being said there are also tags for those who like a flatter structure.

[1] https://supernotes.app

If only symlinks worked for every software / OS. On Windows at least, there are so many different way to link things (including "subst") that it's hard to get idea which one to use. (I do love symlinks, but having spent most of my time on Windows, there are some edge cases I've hit, for example some third_party software not following the symlink and simply failing to open the file..., and no that was not the old .lnk style link)

mklink if anyone is curious. It can act oddly in a few cases. Especially if you cross volume/network boundries.

Is there some reason that a filesystem couldn't be written to permit multiple paths to the same file without the clunkiness of sym links?

That's a hard link. They have problems too.

Unix has supported multiple paths pointing to the same inode for a very long time. `man ln`.

(Windows) NTFS has hard links which are multiple pointers to the same file, but I imagine that the strict separation between FSes that made it possible in NT is also the reason why Unix, which has a single arbitrary hierarchy, doesn't have hard links.*

* Yes there are hard links, but the single hierarchy means that unless you memorised the specific FS of each folder, it's gonna be hard.

That would be a hard link, though they can't cross filesystem boundaries.

The problem with multiple paths leading to the same file isn't with the file system, but with the file system users. When you're writing scripts or programs against file systems it is really convenient to assume that each filename is one and only one file, that the file has a unique name, and that the file system is strictly a tree.

File systems can technically break all of these; files can contain multiple files within themselves with many file systems, the ability to have multiple paths leading to the same file means that if you just have the file in hand you don't have a unique path, which also means that if you remove that name it doesn't mean you've removed the file. But most of the time, you can kinda get away with writing normal code and it'll do the right thing. But that last one really burns. It is really easy to write code assuming file systems are just trees, and in particular can't have infinite loops, and be wrong about that.

i make extensive use of hardlinks in my files (especially with photos), and i don't see the problem. if i remove a file, i don't usually want it gone completely, but i want removed from this particular location, if it is hardlinked elsewhere, i usually still want to keep it there.

if i want to really remove it, i can scrub the contents without removing the hardlink, and if i want to delete after scrubbing i check the hardlink count and search for the remaining entries.

Doesn’t a lot of software break hardlinks on edit? I think non-database software usually completely replaces the file via overwrite or atomic rename.

Sometimes you might want that behavior, but other times you might not. But there’s no option in any app I’ve seen to choose how to handle hardlinks on edit/save.

yes, i consider this a conceptual design flaw in unix. effectively i think a better way to do this would be if the move or copy operation onto an existing file would move/copy the content of that file onto the target inode. there could be a seperate rename operation which keeps the current behavior

fortunately in my case this issue is not a problem. i use hardlinks mainly for pictures where i never want to replace the original anyways, so editing always gets me a copy which i don't need to link to multiple places.

I have the answer it's a graph based filesystem! Just kidding I don't really have an "answer" just your question inspired me to Google for a graph based file system.

https://fsgeek.ca/2019/05/09/graph-file-systems/

Reply on news.ycombinator.com