you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 9 months ago* (last edited 9 months ago) (2 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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 9 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 9 months ago* (last edited 9 months 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.

  • source
  • parent