I messed with TMSU back one of the previous times it was posted. It's very cool and works well but I just couldn't make myself go retroactively apply tags to terabytes of existing files.
It almost feels like a personal categorization version of the "AI Bitter Lesson": people keep thinking that doing a bunch of manual taxonomy work is going to help them find files faster but eventually search catches up
> people keep thinking that doing a bunch of manual taxonomy work is going to help them find files faster but eventually search catches up
This. I spent many days cataloging, tagging, deduping and organising my photo and data files, programs, bookmarks, etc.
And I've barely used any of those photos or data files since. The time invested totally wasn't well spent, and I should have just left everything called "DSC0000565.jpg".
> retroactively apply tags to terabytes of existing files
This has always felt like one of the primary issues with tag-based lookup over hierarchical. By the time you're knee deep with enough stuff that you realise tags would help, you've already accumulated too much to practically deal with.
That and figuring out what the tags should be upfront and hoping you don't realise you need additional or different tags later on.
Only to the files you can already easily find with find grep plocate etc
That's because they are already tagged via path, or in the file. I'm just going to wait for multimodal LLM tagging solutions to catch up, rather than just try to hack it with current models/tech.
Something like this just for photos has been in the back of my mind forever - it would be really nice to have a virtual folder built from images where the exif data says you used X camera or took the photos on X date. This would be useful for editing applications that are not catalog based, just point them at the virtual folder and query the images you want to edit, and there they are.
Edit - Someone mentioned befs but deleted their comment, it seems like it might sorta be supported in modern linux, possibly just read only though:
I'm the guilty party who deleted the comment re: BeFS. I thought my analysis of the project was a little biting and, aside from mentioning BeFS, I didn't think my comment was adding much.
I thought about photos and EXIF tags, too. Duplicating the data from the EXIF into another repository strikes me as a bad idea. That's why I was pining for BeFS.
(I have a lot of crazy ideas about filesystems (arguably more like digital asset management systems) and data ingestion and export. Ideas kind of like the failed WinFS. Nothing will ever come of it because I don't have the skills or the time, but sometimes in fever dreams I imagine this stuff.)
With regard to BeFS or BFS the native BeOS (and Haiku) filesystem.
The TSMU examples for mp3 files + VFS are similar to BeOS.
One of the BeOS advocates - Scott Hacker - created bash script for ripping CDs into MP3s called RipEnc. It would query the CDDB to get the metadata - track names/artists etc, so the files would be renamed from TRACK1 to e.g. "Dead Milkmen - Punk Rock Girl" for the CD. It would then convert the CD tracks to MP3 files. The metadata would be added both in the MP3 ID3 fields, as well as to the extended attributes of the files in BFS, and it would organize the music in folders by Artist or Album or something.
You could then have a query - a virtual folder/directory that lists files based on extended attributes - all mp3 files by ARTIST foo, and from ALBUM bar, that would stay updated if the file metadata changed. I can't remember if this virtual directory was available at the command line - or if it was only available in Tracker (the native BeOS/Haiku file manager).
The problem with this, and it's not just a BFS problem, is that the metadata in the file and about the file get can get un-synced, either when updating it, or transferring it to another system that doesn't support the extended attributes.
If you mostly want to query and can live without the VFS, dogsheep[1] is your friend. It's a general tool to import lots of different data types into a personal sqlite instance, and dogsheep-photos[2] both extracts image metadata and uploads all the pics to S3 if you'd like.
On my to-try list, there's also supertag[3], a tag-based filesystem that's mounted via FUSE
I've used exif-database for something similar but it doesn't build the folder, it just lets you query the sqlite database to find what you are looking for.
I have 41k photos in my Lightroom catalog, I’ve checked it out.
That doesn’t work when I want to use Capture One, Lightroom does not apply Phase One calibration profiles which makes it useless for them, or my own raw processor for Sinar digital backs.
Recommending the most common digital photo DAM/editor is not really a helpful comment either. The number of people who know what exif is and don’t know about Lightroom has to be…small.
I'll admit when I first saw this, I was put off by the idea of having a separate tool to do something that _should_ be baked into the filesystem. But honestly, this a pretty close to a very Unixy way of solving the problem. Have a separate (and importantly: optional) tool that does the job and does it well.
Additionally, Linux _does_ support tagging files right in the filesystem via the user.xdg.tags xattr. Although it looks like Dolphin is one of the few userspace tools that knows about it.
This reminds me a bit of the DESCRIBE command in 4DOS ca. 35 years ago [0]. It was only a single text entry per file, but supported by many tools [1], including file managers. There was a proposal to extend the format to XMP properties [2].
Yoo this is such a great idea , I once saw a video of a youtuber creating open source tag software and I don't know , I realized a frustration and I was also needing something like this once and I was installing this tag cli tool
but this seems even better, this is why I am on hackernews
xattrs are great, and would the obvious solution for tags/metadata on Linux too, if the syscall API didn't delete them at every opportunity; programs must be explicitly told not to do that.
There's multiple projects that attempt similar thing with SQLite, most recent one being Tag Studio. Seems like tag-based file organization is better solution but required mental cost/effort of upkeep is what keeps it from gaining any traction in long run
Since it is baked into the file system, it is pretty easy to create bash scripts to add keyword tags by parsing the directory tree (e.g. batch add tags to books, movies, videos, etc stored in hierarchical category directories).
Most apps have flags to be used to preserve xattrs. Others were written as though they never knew xattr existed and therefore fail to use the kernel flags to preserve them. But it is not that difficult to preserve them once you are using them.
I use rsync to back up my book, music, and video collections (which is where I use them) and the meta data is backed up with them - so if something ever happens I can always restore them. The xattr commands also have a backup and restore for just the xattr built in.
The hardest(most inefficient) part is finding out what tags a file has.
find . -samefile group/beatles/love_me_do
album/please please me/side 2/1
vocals/paul mcartney/love me do
vocals/john lennon/love me do
year/1963/love me do
group/beatles/love me do
You have to love ontology to go down this route. I do, and did this once... It is possible, but does not really provide any meaningful advantage.
I really wanted this to exist about 15 years ago, but at the time didn't have the skills to make it happen. Nowadays though I'd want something that can sync across between Linux and Android at the very least. But I've gotten to comfortable with find and grep to bother.
If you are interested in one of the absolute worst ideas that worked flawlessly over the years: I wrote a 100-line python script that just appends a magic number and one or more tags as ascii at the end of an arbitrary file.
I mostly use it to tag media files (music, video, photos), pdfs, docs/spreadsheets. So far I haven't encountered any issues. But obviously if you tag a plain text file you are gonna see the tags at the end.
Nice idea, all these type of databases should indeed support both hierarchies and tags for any decent organization, but no gui and no update tracking - unfortunately, that's way too limiting
The fact that some kind of tags or Key/Value storage as attributes on files, has been missing until 2025 (and still is) seems so bizarre to me. Our file systems have hardly changed since the 1960s. We get filename, timestamp, filesize, and that's about it. Pathetic.
Imagine the opportunities if a folder structure could represent a "document" where each file represents a paragraph, or image, chunk of that document. We would be able to do 'block-based editors' (like content management systems, or Jupyter Notebooks) without having to have some large XML file holding everything.
Even if we had simple "ordinal" (ordered position) for files that would open up endless opportunities for innovation in the 'block-editor' space, but sadly File Systems development has been frozen in place for decades.
That still looks pretty hierarchical. I think the point of tags vs something like categories is that a file can have multiple independent tags. Your system can do it with symlinks too of course.
It almost feels like a personal categorization version of the "AI Bitter Lesson": people keep thinking that doing a bunch of manual taxonomy work is going to help them find files faster but eventually search catches up