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.
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.
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.
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.
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.
deleted by creator
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,
findslowly 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.