5 ms·

While I don't remember that specific project's name, I do remember that a lot of that was possible because files in a filesystem often aren't just some hierarch

While I don't remember that specific project's name, I do remember that a lot of that was possible because files in a filesystem often aren't just some hierarchical folder structure. There is often a tree-like structure to be able to find a single file quickly amongst many files, but there was no technical reason why it wouldn't also support off-tree indexing based on tags. I imagine one of the problems you'd run in to is mass updates since deleting a directory with many files in it below a single tree node is very much limited to that part of the filesystem's tree, but doing it with tags causes updates all over the place. It does remind me of this more metadata-like FS: https://github.com/marook/tagfs https://github.com/marook/tagfs As well as the thing Apple does in Finder where it has a tag database and dynamic 'tag' directories where it shows you everything that was tagged with that tag. Then the search function would allow selecting files based on tags so you can do many-tag searches and only find the files that match all of them. I think that one is based on an in-filesystem metadata stream.

jbergens 5y ago
I think the article was about making it easier for users. It may not be easy anymore if they have to use directories AND tags. Or it may work, if the only files they normally tag are their documents. Tags have a problem with names. How do you stop users from messing with files that belong to the OS or some application? Should we require that they all have the tags "OS" or "app" on them? Should binaries have the tag "binary"? What happens when the user tries to delete one app but chooses "tag 'app' and name startswith 'word'"? Should all application files named "word"-something from different applications be removed? Should the user have known to use a meta-query with "tag 'app' and tagname:startswith 'word'"? I do see a lot of problems but of course some things would be easier.
- 6510 5y ago
  At least that part of the puzzle is obvious: Users should never touch system files nor have to look at them. I never want to see any asfawe.sdwae file ever again. Its like keeping power tools in the cup board or having screwdrivers in your utensils drawer. Its like keeping the manual in the washing machine. You open the door and instantly know it's a ridiculous idea. The user should be able to do what he wants, anything should go, there should not be any bad moves besides deleting their own stuff, they should be able to simply delete everything. Make it a partition with a warning prompt.

jbergens 5y ago

I think the article was about making it easier for users. It may not be easy anymore if they have to use directories AND tags. Or it may work, if the only files they normally tag are their documents. Tags have a problem with names. How do you stop users from messing with files that belong to the OS or some application? Should we require that they all have the tags "OS" or "app" on them? Should binaries have the tag "binary"? What happens when the user tries to delete one app but chooses "tag 'app' and name startswith 'word'"? Should all application files named "word"-something from different applications be removed? Should the user have known to use a meta-query with "tag 'app' and tagname:startswith 'word'"? I do see a lot of problems but of course some things would be easier.

6510 5y ago
At least that part of the puzzle is obvious: Users should never touch system files nor have to look at them. I never want to see any asfawe.sdwae file ever again. Its like keeping power tools in the cup board or having screwdrivers in your utensils drawer. Its like keeping the manual in the washing machine. You open the door and instantly know it's a ridiculous idea. The user should be able to do what he wants, anything should go, there should not be any bad moves besides deleting their own stuff, they should be able to simply delete everything. Make it a partition with a warning prompt.