Symantic Filesystem

You'd need to delete the file hash from the database, then delete the whole directory that all the hardlinks are in for that file.

I'm not sure how I want to implement deletion yet, which is why I haven't finished it. I have some ideas you can add to.

* When a file is removed from all tags, it's deleted from the database.
* Files can't be removed from the filesystem normally. An admin has to use a tool that cleans files without tags, and can back them up
* Files can be moved to a special "trash" tag that either deletes them immediately, or marks them for deletion by the admin tool.
* All files are in a special "all" tag, deleting the from that tag deletes them for real.

Any suggestions?

If you're going to try deleting things now, remember to use the foreign key pragma in SQLite, since that dbms doesn't cascade delete by default. Just remove the hash from the file table, and all its tag entries will be deleted too.

I haven't heard of that. Is that the other thread here if the user that made a Booru accidentally? I think the symlinks in directories method isn't scalable. It requires a file write for each tag a file has, and a tag with many files will be slow to search through. See the directory tree I posted in OP? The first 3 characters in the file hash are directories, so there's never more than 255 entries in the root directory.

elaborate or stop posting

Ah blooblooobloo, muh ancap rice.

Don't listen to the suckless faggot, GPLv3 is what you want.
If anyone wants to see the end result of too permissive license look at the bitching of Antirez; "OH GOD I SAID THEY COULD DO ANYTHING AND THEY DID, THEY'RE NOT EVEN CONTRIBUTING BACK!".
GPL solves this problem.

Sure will do in some days since I got school shit to do but I think you could tag your files by just organizing them in folders.

see my response here

There's scalability issues to simply putting symlinks in directories. If you look at the overhead, an SQL database is less bloated than symlinks in directories, albeit more complicated. There's less reads and writes, and listing a directory with too many files in it is slower than querying a database with that many entries. I also can't imagine how to implement ontology or triple tags when using symlinks in directories.

TMSU's backend is sqlite3, and the symlinks are generated on the fly when you browse the virtual file system. An OK workflow is:

1) Download file into some directory structure
2) Use a `tmsu tag myfile tag1 tag2 tag3` command to tag the file
3) When you want to find your file, you navigate to `/path/to/tmsu-vfs-mount/queries/"(tag1 or tag2) tag3 not tag4"` and you see a bunch of symlinks to relevant files.

You can even tell TMSU that tag1 implies tag2. The only real drawback imo is that you have to manually tag files using commands (there's no writing to the virtual file system).

Basically just consider hacking on github.com/oniony/TMSU instead of rewriting everything from scratch. It's written in golang, and it works on Alpine as long as you remove GNU specific extentions from the makefile.

Start over from scratch, in C, or fork an existing simple FS (like OpenBSD's FFS) and toy with the file table code instead, and use the BSD two-clause.
On second thought, you don't seem ready. Good luck nooblet!

sqlite is the least pozzed and most highly tested DB ever. wtf do you have against

It's so reliable the US military uses it, it's an actually succesful FOSS project that puts Linux to shame, it has the best license I have ever seen, and the entire dev team is both politically sane and gifted with a good sense of humor (see their CoC).