Why in all operating systems files are organized in exclusive directories rather than freely intersecting sets?

By using tags?
Not very difficult broseph.

Put them all in one directory and tag the files?

nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies

>and to answer your question: because it makes the most sense
>Because it would be a nightmare to maintain and use
>Because you usually don't want that
Pure presentism.

only certain types of files can be tagged

because legacy file systems

>muh 16bit data structures
>muh 8 bit data structures
>muh 4 bit data structures

we should just be searching all files from one directory but we arent and we shouldnt and this is another level removed from freely interacting sects

>doing things the easy way is presentism

Attached: idiot.png (499x338, 38K)

What files would you want to use tags on that you can't tag?

I remember KDE trying to introduce the "Semantic Desktop". It was a miserable failure, and I remember disabling it as quickly as possible. The idea wasn't horrible, but the implementation was.

>no monster girl/foot worship intersect

various formats of text
gifs
pdfs
archives
m3us
folders

btrfs does this

Custom database solution and frontend.

Either that or some hyper convoluted overlaying.

How would a semantic system be browsed? Would it basically have to be presented as tags and you'd navigate them as common folder based file manager?

>what are shortcuts

I really want an OS to properly implement this.
for the time being, theres TMSU.

or put them all in one directory, have a folder for each category then create symlinks in those?

How practical is TMSU?

People have used FUSE to implement some pretty silly shit.
So go and write it yourself.

>I'll take what is a hard link for 500

With a tree it all starts from the "/" node and you can browser through it normally, with sets how can I browse from set A to set B if their intersection is empty?

KDE dolphin with BTRFS XATTR

This and sym/hardlinks

>change a file in one location
>it changes a file in a completely different and unexpected location

10/10

Sounds like a you problem. I can tag .gif, .pdf, and .exe files and I'm not even running Windows.

You're not properly wrapping your mind around this. You're changing one single file in multiple locations. If changing a file in one directory shouldn't change the file in the other directory then they should be separate files.

Because a tree is 1 dimensional space for brainlets.
Good luck getting people to operate in infinite dimensions

kys

Not trying to defend OP(directories are better IMO), but I think no such case like that would exist. There would always be a universal set to connect all of them.

See:
/Thread

Brainlets are dragging down user interfaces to the lowest common denominator

>mfw this thread

Attached: index.jpg (310x163, 7K)

Fuckin' use your database-like filesystem, add extra attributes to your files and use live queries.
So use Haiku.

I'd imagine like a booru, maybe.

Ok give me one reason what you want needs to be done or will result in any sort of improvement
Bonus: prove me how not using a binary tree for directory structure will keep same indexing performance

>What are tags?
APFS supports this. Can just tag the sets it's in, then freely browse through the tag groups.

you mean tags instead of folders?

uriel? is that you...?

Yet another reason to purchase the new Apple Macbook Pro with Retina Display.

>what are hard links
It is like you don't know the filesystem you're using OP

how

softlinks are just pointers to files, and can be dead/dangling, they are annoying to deal with.
hardlinks increase the inode ref counter, so if you "rm" one of these hardlinks, the file will not be gone from the disk/fs (just from one particular set) if there's still a hardlink somewhere else to the same inode.

using symlinks (hard or soft) for tagging is retarded.

This diagram is fucked. The overlaps and subsets make no fucking sense. Get better taste.

>what are hard and soft symlinks

>tags
this

>hard symlink
>hard symbolic link
senpaialam, symbolic links are soft by definition, there are no "hard symlinks"

>hardlinks increase the inode ref counter, so if you "rm" one of these hardlinks, the file will not be gone from the disk/fs (just from one particular set) if there's still a hardlink somewhere else to the same inode.
Yes. And it does, contrast to symlinks, what OP asks for.
>a file simultaneously be in 2 or more directories none of which is a subdirectory of another
Being able to remove a file from multiple sets simultaneously wasn't asked for.

Use a program that manages and shows files by tags

>make illegal-stuff set
>link every dodgy file from other sets into it
>rm -r illegal-stuff/
>every dodgy file still around

>inb4 but you can still find -inum $(ls -i squirrelporn-17234.mpeg | cut -d' ' -f1) -exec rm {} \;

>not buying their best product

Attached: MJYR2.jpg (572x572, 65K)

>Ok give me one reason what you want needs to be done or will result in any sort of improvement
You don't have to worry about or remember how to navigate to a specific file, nor worry that a specific file you found isn't a (potentially out of date) copy of a specific file instead of what you were actually looking for.
You can edit the properties of the files, including things like permissions, launch arguments, and "location"-equivalent without having to edit or fix a bunch of references to it.
>Bonus: prove me how not using a binary tree for directory structure will keep same indexing performance
All of your actual files can be more easily meaningfully sorted before even getting to indexing.
Since you don't need to follow multiple levels of pointers to get to files, there will be less arbitrarily disjointed indexing in the first place.
It better supports the creation and maintenance of having multiple indexes that are specialized, especially in regards to dynamically merging, or creating subsets of, indexes.

There's a reason many databases are set up in a similar fashion. Obviously there are also a bunch of downsides, such as manual effort being required to "tag" files that computers wouldn't be able to, or would have a hard time being able to, automatically. One of these two methodologies isn't outright better than the other--they have tradeoffs that make one better than the other for certain applications.

The real question shouldn't be "Why do we not use this instead of that?", but rather "Why isn't there a popular and standardized filesystem that allows for both of these methodologies to be (seamlessly) mixed together without partitioning.

Most operating systems are designed to accommodate the dumbest users that would use their system, and unnecessary complexity doesn't help power users either. Adding parallel/competing organizational systems would complicate things and only be useful to a small subset of their user-base. The people who actually need/want a tagging organizational system have many options to choose from, and they probably mostly prefer having the choices and independence from the operating system.

>seamlessly
You can't adjoin conflicting organization hierarchies without seams user. Maybe you can get the seams you like or can ignore, but others might not agree.

>You can't adjoin conflicting organization hierarchies without seams user. Maybe you can get the seams you like or can ignore, but others might not agree.
If you add a path as a tag that could essentially be the same as having the file in that path in a hierarchical FS etc.
If you have a hierarchical FS you need to specify the complete path to some file in order to get it.
That could be relatively seamlessly integrated into a tagFS, I think. For example if you download a file it automatically gets the tag /home/user/downloads/ and a name tag filename.extension . And so on. Moving a file from folder a to b you remove the existing path tag and add a new one that puts the file in folder a.
Then the file browsers address bar (for example) can work just as normal if the FS implements translation of a path to a path-tag.

>Why can't a file simultaneously be in 2 or more directories none of which is a subdirectory of another?
Because the hierarchical file system is a cheap hack. People noticed this in the 1970s, OP.
>The Nightmare of Hierarchical Directories
>Hierarchical directories were invented around 1947-- it seems impossible to find out when or by whom-- when somebody said, "How are we going to keep track of all these files?" And somebody else probably+ said, "Gee, why don't we make a file that's a list of filenames?" And that was the directory. It's a temporary fix that scales up in the wrong way.
>Real projects for ordinary people tend to overlap, interpenetrate, and constantly change. The software requirement of their staying in one place with a fixed name is inane. The problem is much harder.
hyperland.com/TedCompOneLiners

Really the only correct solution unless you want to create a new filesystem.

There are many attempts to do just that, they are called Database file systems.

For Linux there is this one called TagFS, Microsoft tried to make one called WinFS but they canned it.

Alternatively, if you have such amounts of massive data, you can use a database like SQLite and just use that.

How to do it?

A directory is just a file that's a list of files, so just edit that file to point to files wherever you'd like.
Simple.

They can be. Look up hard links.

en.wikipedia.org/wiki/WinFS
hydrusnetwork.github.io/hydrus/

By right clicking the file and selecting "Tag" then applying whatever tags I want to it

>zdnet.com/article/bill-gates-biggest-microsoft-product-regret-winfs/

IT HURTS

Tell me about it.

But honestly, I'm kinda glad that it turned out that way because if WinFS had really happened I would probably be stuck forever on windows.

I feel like it would have probably influenced design on other operating systems, teams would have had to come up with something on par if the benefit was really there. But no splash means no impact even if someone could have made an open alternative in all this time, most people don't even consider the concept.

hardlinks, actually.

Can we turn this into a Data Curation thread?

I have severe autism and have been trying to create my perfect, personal file structure for a week now.

just read a little about it, it sounded a bit too good to be true
doesn't anyone have a copy of the beta versions microsoft released though?

What's your shot on the problem?

> What are hard links.

Sure, those are out there but without widespread use and iterations/patches, it's not really practical for use.

because its a LOT less efficient for searching for files, which slows down your entire operating system. machine brains dont work the same as human ones do, so just because theres an easier way for you to think about and memorize things doesnt mean its easier for the computer at all.

I'm not really seeing any practical advantages to that, and at least a few use cases where it screws things up. But if you really want to, hard links.

Would something content-addressed like IPFS suite your needs?