am regularly amazed that we pretend folders are the right way to organise files. They’re entirely arbitrary. Every competent file system ignores them to its best ability. Why can’t I have a file in two folders? Why does one have to be a “reference”? Why can’t I filter for files that exist in 3 folders with X extension?
We’ve been played for absolute fools.
We have hard links, but is there any good UI out there for them? I only know of using the
lncommand directly. Or put another way, do you know of anyone who actually uses hard links in a way similar to how a tagging filesystem would be used? What are the obstacles that prevent this use case from being easy or discoverable enough to be in common use?With a tagging system you can remove tags without fear of losing file data. But with hard links you could easily delete the last link without realizing that it's the last link, and then the file is gone.
That relates to another issue: in a tagging system you can look at file metadata to see all of the file's tags. Is there a convenient way to do that with hard links? I see there is
find . -samefile /path/to/one/link, but requiring a filesystem scan is not optimal.No, in nearly every case, you never want a hard link. You want one file, and symlinks to it. (Technically every file is a hard link to an inode, and subsequent ones are just additional links to the same inode.) In ext4, you can't easily get a list of links to an inode, you have to scan the filesystem and look for duplicates. Other filesystems might make this easier.
You shouldn't try to use a tree filesystem to approximate a tagged database. Use the appropriate tool for the job.
That's not an unreasonable answer. But I find this thread a little frustrating. As I see it, it's gone like this:
Why bring up hard links if people shouldn't use them for the requested use case? I mean, I do think your original reply was interesting and relevant as a starting point to get to what I think OP has in mind. But that line of thinking does require getting into how to use hard links for a non-hierarchical workflow.
I feel like OP was trying to start a discussion about what might be, if things were different. I tried to reply in the same spirit. I feel like I'm asking, "What if things were different?", and I'm being told "It doesn't work that way." Which doesn't feel like an especially helpful response to me.
I mean there are better tools, such as TMSU or tagfs, which i think are actually better approaches to having (part of) your file system displayed in a non-hierarchical way - or rather in a dynamic hierarchy.
But the other poster is also right in that for your system file system, i.e. root and operating-system critical paths, do not benefit from such an approach. I think asking for such a thing kind of sounds like an XY problem and requires listing the actual problems to solve with an alternative approach first.
If my grandmother had wheels, she'd be a bicycle. Don't try to force a hierarchical filesystem into other applications. Asking "what it if was different" doesn't make sense, because if ext4 was a tagging filesystem, it would be tagfs! Tagfs and others already exist, you can use them today! Go crazy, use object or document stores! Embed everything in xml! But for operating systems or actual human interface, those are terrible ideas, which is why we don't do that.
I brought up hard links to say "yes, you can do that, but it doesn't mean you should". There are few cases for hard links. The only one I've seen in actual use is in media downloaders, where a file gets downloaded to one folder, then hardlinked from a library folder, so that you don't have two copies of that video. The library (jellyfin) can do whatever it wants to the link (move, rename) while the downloader (qbittorrent) can still keepit for seeding, and either side can happily delete its copy without affecting the other.
Most people don't need a file to be in two places at once, it's more confusing than convenient. And if they do want two of a file at all, they almost certainly want them to be separate copies so that the original stays unmodified when they edit the second one. Anyone who really wants a hard link is probably comfortable with the command line, or should get comfortable.
The Mac actually kind of gets the best of both worlds, APFS can clone a file such that they aren't hard links but still share the same blocks of data on disk, so the second file takes up no more space, and it's only when a block gets edited that it diverges from the other one and takes up more space, while the unmodified blocks remain shared. It happens when copy-pasting or duplicating a file in the Finder as well as with
cpon the command line. I'm sure other modern file systems have this as well.