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.
Edit - Someone mentioned befs but deleted their comment, it seems like it might sorta be supported in modern linux, possibly just read only though:
https://github.com/torvalds/linux/tree/master/fs/befs