this post was submitted on 31 Jan 2026
207 points (98.6% liked)

Linux

11641 readers
462 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] MonkderVierte@lemmy.zip 1 points 11 hours ago* (last edited 11 hours ago) (1 children)

No, they always have to keep a index uptodate. And no synch (or even compatibility) with other such tooling. Only thing that comes close currently is xattributes some fs support. But they are wholly a undefined blank slate.

About advantages, no broken paths would be one.

[–] balsoft@lemmy.ml 2 points 11 hours ago (2 children)

Dolphin (well, whatever the KDE's indexer is called) uses xattrs under the hood for tagging, so it will be compatible with other software (including {get,set}fattr).

The index has to be up-to-date, but then that would be true with any tag-based filesystem, it's just happening on a different layer (and arguably a layer which is more suitable for this - not sure it'd be a good idea to enforce synchronous indexing during xattr writes).

The most significant user-facing obstacle is lack of software which supports this system, but I guess that shows that there's not much desire for it in reality.

[–] MonkderVierte@lemmy.zip 1 points 10 hours ago* (last edited 9 hours ago)

Right, i remembered KDE using xattr just after writing the answer. But still, only a KDE convention how the data is stored, not a fs convention.

But my point was, we could entirely get rid of file trees. How many times did i wish, find slowly traversing the fs tree, that you could define a bit more details than the name and roughly if it is a file, a directory or a symlink. Working on a small trashdir shell script currently, there is a .trashinfo file with the date deleted and the last used path; that's a hack, not a solution. The fs index could contain things like mime type, intended use (library, executable, plaintext), advanced security context, deleted/visibility, without storing a tree the tooling has to hang on to. Finding stuff on the whole disk could be instantaneous.

And yeah, of course this would be incompatible to everything *nix and Windows currently. Which is why i think it would need to be a whole new OS (with compatibility tooling to *nix). Current *nix kernels have a lot of Server-centric assumptions the distro tooling has to work around for desktop use anyway. The file systems also, they were made for server-centric use in times of MB, not TB. ext3/4 are just iterations over the old thing, with higher limits, better optimized algorithms, and so on.