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.
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.